mirror of
https://github.com/PR0M3TH3AN/bitvid.git
synced 2026-10-27 07:52:24 +00:00
Real-env console (2026-06-15) showed that once the extension's message
port drops under the post-login burst ("message channel closed"), EVERY
subsequent decrypt call hangs to its full ~15s timeout. Each list service
(blocks, hashtags, subscriptions, watch history) independently retries on
that timeout, so the app sits in a permanent loop of 15s-blocking
extension calls — pinning the CPU ("fans at max") and never recovering
until a manual page refresh.
Add a shared circuit breaker at the runNip07WithRetry chokepoint:
- After CIRCUIT_TIMEOUT_THRESHOLD (3) consecutive timeouts the circuit
OPENS; further calls fail fast with code "nip07-channel-unresponsive"
(no multi-second hang), so the retry loops become cheap and the CPU
settles.
- While open, a single probe per CIRCUIT_PROBE_INTERVAL_MS is allowed
through; one success CLOSES the circuit and normal decryption resumes —
no page refresh required.
- Responsive failures (extension answered with an error) reset the
timeout streak — only genuine channel hangs open the circuit.
- Interactive permission prompts bypass the breaker entirely: a user
taking their time at the extension UI can neither trip it nor be
blocked by it, and such a prompt can itself heal the channel.
Increment 2 of the "cut the login burst, then add a safety net" work for
KNOWN_BUGS #0. Test: tests/nostr/nip07-channel-breaker.test.mjs
(cheat-resistant — drives the real queue with hanging/responsive/success
ops; asserts open-after-threshold, fast-fail, probe-recovery, responsive
errors don't open, and bypass is never fast-failed). Full unit suite green.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
8.4 KiB
8.4 KiB
Known Bugs (deferred)
Running list of confirmed bugs/limitations found during the data-flow refactor (see architecture-refactor.md) that we chose to fix later rather than block the current phase. Distinct from the planned refactor work in that doc — these are defects.
Format: [severity] short title — where — what — suggested fix / phase.
Open
0. Encrypted lists (hashtags, DMs, blocks) fail to DECRYPT on login (top priority)
- Severity: high — the user's recurring "hashtags/DMs/watch-history don't load in the profile modal."
- Diagnosed from real-env console (2026-06-14): the lists are fetched (e.g.
block events
Array(2)) but decryption fails, three different ways:- DMs:
DM decryption helpers are unavailable(client.jslistDirectMessages →buildDmDecryptContextreturns 0 decryptors → hard throw, no retry). Happens whenensureExtensionPermissionsreturnsok:false. - Blocks:
Decryption timed out; signerStatus: 'missing'/'unknown'(userBlocks.jsapplyEvents) — the signer/decrypt capability isn't resolved. - Hashtags:
Decryption timed out after 6s(hashtagPreferencesService.js).
- DMs:
- Root cause (strong): a relay-connection STORM. On cold load the app opens
WebSockets to the user's full ~20-relay NIP-65 list (most dead) because
subsystems build relay lists from
relayManager.getReadRelayUrls()+getWriteRelayUrls()(uncapped) — e.g.userBlocks.loadBlocksInternal. The dozens of failing connections churn the main thread and starve the nip-07 extension's postMessage round-trips → permission/decrypt calls fail or time out. - Partial mitigation shipped: hashtag + subscription decrypt timeout 6s→15s.
- Relay-storm fix SHIPPED (2026-06-14):
capReadRelays(injs/nostr/toolkit.js) bounds every read/subscribe path toMAX_SUBSCRIBE_RELAYS = 8, applied centrally at the chokepoints —client.jsapplyRelayPreferences(this.relays/readRelays) andrelayBatchFetcher.jsfetchListIncrementally(used by blocks, subs, hashtags). Writes stay uncapped. The helper is user-relays-first (a user's own relays are where their data authoritatively lives, and small fast-path limits would otherwise crowd them out — the bug that broke the first attempt) while RESERVINGRESERVED_DEFAULT_RELAY_SLOTS = 2for the reliable default aggregators so the "~20 personal relays, all dead" case still reaches a live relay. Test-aware: under test the reserved core is the test-relay override, so harnesses stay isolated. Regression coverage:tests/relay-subscribe-cap.test.mjs(bounded + reserved-defaults + writes-uncapped), and the spec-correcteduser-blocks,subscriptions-manager, andnostr/clientfetch tests. - Real-env follow-up (2026-06-15 console): the relay cap WORKED (every sub
now fans out to exactly 8 relays) but exposed the true blocker: under the
post-login burst the nip-07 extension's message port drops ("message channel
closed"), after which EVERY decrypt hangs to its ~15s timeout, each list
service retries forever, and the app never recovers without a page refresh
(CPU pinned — "fans at max"). The signer-readiness gate also took ~67s.
Two-part fix in progress ("cut the burst, then add a safety net"):
- Burst reduction (SHIPPED, increment 1): stop eagerly loading DM history
at login (
authSessionCoordinatordmStatePromisenow defers; DMs load lazily when the Messages tab opens). Removes a 50-message decrypt burst that competed for the channel. Test:tests/app/login-defers-dms.test.mjs. - Channel circuit breaker (SHIPPED, increment 2):
js/nostr/nip07Permissions.jsnow opens a circuit afterCIRCUIT_TIMEOUT_THRESHOLDconsecutive call timeouts — subsequent calls fail FAST (code: "nip07-channel-unresponsive") instead of each hanging ~15s, so the per-list retry loops stop pinning the CPU. A single periodic probe detects recovery; one success closes the circuit (no refresh). Responsive errors don't open it; interactive permission prompts bypass it. Test:tests/nostr/nip07-channel-breaker.test.mjs.
- Burst reduction (SHIPPED, increment 1): stop eagerly loading DM history
at login (
- Still open: further burst reduction (collapse each list's multi-variant fan-out into one multi-filter REQ per relay; investigate the ~67s signer gate); liveness-ranked relay health (see #4); DM decrypt resilience (don't hard-fail DMs on a transient permission miss — retry).
1. Logged-out: video grid stays empty until a manual refresh
- Severity: medium (first-load UX, logged-out).
- Where: initial feed render path (
js/index.jsdisclaimer flow →viewManager→feedCoordinator); rendering is a side-effect of event ordering. - Symptom: logged out, after dismissing the disclaimer the grid doesn't populate until the page is refreshed.
- Root cause (suspected): the grid paints as a side-effect of a data event that can fire before the grid container is mounted (render coupled to event ordering, not to state).
- Fix: P5 — unidirectional flow: render from AppState whenever it changes, decoupled from event ordering. Could not reproduce headlessly (real-relay feed returned nothing in the sandbox); reproduce in a real browser first.
2. Residual full-feed reload loop on list-loaded signals — FIXED (P5)
- Status: RESOLVED 2026-06-14.
handleBlocksLoadednow reloads the feed only when the block-set signature actually changes (emit-on-change guard);handleRelaysLoadedonly refreshes the relay UI (never the feed), andhandleHashtagPreferencesChangealready deduped by signature. Regression test:tests/app/blocks-loaded-reload-guard.test.mjs(cheat-resistant).
3. Direct-pool-access lint still misses MULTI-LINE access
- Severity: low (tooling gap — weakens the L1 chokepoint guarantee).
- Status: partially fixed — the regex now catches bare
pool.sub(/pool.list((re-baselined to 22 files). Still MISSES access split across lines, e.g.js/services/profileMetadataService.jswritesnostr.poolnewline.list(— so profiles is an unflagged fetch source. - Fix: normalize whitespace before matching (collapse
\.pool\s*\n\s*\.list) or move to an AST/grep -A1check. Add profileMetadataService (and any other multi-line offenders) to the allowlist once detected.
4. Interim relay cap is static, not liveness-ranked
- Severity: low (acceptable interim).
- Where:
js/nostr/toolkit.jscapReadRelays— bounds the read/subscribe set to 8 (user relays first, 2 slots reserved for reliable defaults) but does NOT re-rank by live health. If a user's first 6 relays are dead, reads lean on the 2 reserved defaults until other paths recover; the dead ones still get a (bounded) connection attempt each cold load. - Fix: P1's deferred
RelayHealth— rank the bounded set by rolling liveness and re-resolve on health changes, so dead relays drop out of the read set entirely instead of consuming slots.
Pre-existing test failures (predate this refactor)
Confirmed failing at the pre-session baseline (4bd9503c) — not caused by the
refactor, but should be triaged. Not in KNOWN_ISSUES.md.
5. tests/nostr-delete-flow.test.mjs
- "deleted events should not trigger subscription callbacks" — a deleted event
reaches the feed callback (buffer delete-filter or dedupe). Investigate the
VideoEventBufferdelete handling.
6. tests/view-counter.test.mjs
- "view event should append the session tag when requested" — view-event publishing tag composition (unrelated to the P3 counting refactor).
7. tests/nostr-count-fallback.test.mjs
- Fails at baseline; NIP-45 COUNT fallback path. Triage.
8. tests/nostr/nip07Permissions.test.js
writeStoredNip07Permissions/clearStoredNip07Permissionsfail under Node (no reallocalStorage). Likely environmental — provide a localStorage shim (seetests/test-helpers/setup-localstorage.mjs) or guard the test.
9. tests/app/hydrate-sidebar-navigation.test.mjs
- Fails at the pre-session baseline (
4bd9503c). Triage.
10. tests/app/is-user-logged-in.test.mjs
- Fails at the pre-session baseline (
4bd9503c). Triage.
Perf follow-ups (not bugs, but tracked)
- One-time login enrichment burst (~75 REQ frames): batched and O(relays), settles to idle, but could be trimmed by hydrating only on-screen cards.
- Remove
js/devReqMonitor.jsimport +scripts/perf/*diagnostics in P6 cleanup once the refactor lands.