mokosh/.planning/phases/01-stabilize-video-pipeline/01-UAT.md

status: partial phase: 01-stabilize-video-pipeline source: - 01-01-SUMMARY.md - 01-02-SUMMARY.md - 01-03-SUMMARY.md - 01-04-SUMMARY.md - 01-05-SUMMARY.md - 01-06-SUMMARY.md - 01-07-SUMMARY.md verifier_residue: 01-VERIFICATION.md (status: human_needed, OPR-1/2/3) started: 2026-05-16T11:14:00Z updated: 2026-05-16T11:58:00Z paused_for: /gsd-debug investigation of Test 3 port-reconnect uncaught-error finding

Current Test

[testing paused — 1 issue + 1 blocked outstanding; user routed to /gsd-debug immediately after Test 3 surfaced 3× Uncaught Error post-reconnect. Resume Test 3 save+play AND Test 4 SW Force-Stop after debug session lands a fix.]

Tests

1. Cold Start Smoke Test

expected: | Run KEEP_PROFILE=0 ./smoke.sh from a clean state. Chrome opens with a fresh /tmp/mokosh-smoke-profile. You manually Load Unpacked the dist/ directory. Extension icon appears in the toolbar. No red errors in the SW console. SW console shows [Background] Service Worker initialized and an OFFSCREEN_READY handshake message. No "Receiving end does not exist" errors. (This catches the bugs that only show on fresh start — orphan IDB cleanup, missing onMessage listener, port handshake race CR-02/CR-03.) result: pass evidence: | User pasted SW console logs from chrome://extensions → service worker:

• Service Worker initialized + initializing (MV3 install + startup, both clean)
• "Cleaned up orphaned VideoRecorderDB" — Plan 01-05 IDB hygiene fires
• "Received message: REQUEST_PERMISSIONS" — popup → SW message routing OK
• "Creating offscreen document at: chrome-extension://.../src/offscreen/index.html" — Plan 01-06 crxjs build output path matches manifest
• "Offscreen port connected" — T-1-04 keepalive port host (CR-02 fix) live
• "Received message: OFFSCREEN_READY" → "OFFSCREEN_READY received" → CR-03 handshake fix verified: SW waits for READY before sending START_RECORDING
• "Sending START_RECORDING to offscreen..." → "START_RECORDING sent successfully" → "Video recording started successfully" Zero errors. Zero "Receiving end does not exist". Critical handshake races (CR-02 + CR-03) confirmed fixed at runtime.

2. OPR-1: getDisplayMedia Picker + Stream Grant

expected: | In the same smoke.sh-launched Chrome, click the extension icon. Chrome's native screen-share picker appears. Because smoke.sh passes --auto-select-desktop-capture-source="Mokosh Smoke Test", the picker auto-accepts the smoke tab — no manual pick needed. "Sharing your screen" banner appears at the top of the Chrome window. SW console shows [Offscreen:Recorder] Stream created (or equivalent). No errors from getDisplayMedia rejection. result: pass evidence: | SW console logs show end-to-end happy path with no errors:

• "Received message: REQUEST_PERMISSIONS" (popup → SW, click registered)
• "Starting video capture for tab 240122995: data:text/html,..." (smoke tab targeted as expected)
• "Creating offscreen document at: chrome-extension://.../src/offscreen/index.html"
• "Offscreen port connected" + "OFFSCREEN_READY received"
• "Sending START_RECORDING to offscreen..." → "START_RECORDING sent successfully"
• "Video recording started successfully" — this final log only fires if MediaRecorder.start() in the offscreen doc completed without throwing, which means getDisplayMedia resolved with a stream (i.e., picker auto-accepted, stream granted, codec assertion passed). Note: "[Offscreen:Recorder] Stream created" log lives in the offscreen page's DevTools console (separate context from SW DevTools); user only shared SW console output. The SW-side "Video recording started successfully" is the equivalent positive signal.

3. OPR-2: Continuous Recording Across Tab Switches

expected: | With recording active (after Test 2), open 2-3 NEW tabs and switch between them rapidly for ~30 seconds. Then click the extension icon → "Сохранить отчёт об ошибке". smoke.sh detects the new session_report_*.zip in ~/Downloads, runs ffprobe (exit 0 expected), stages the WebM to /tmp/mokosh-last_30sec.webm, and opens it in Chrome. The video plays continuously for the full ~30 s with no freeze, no black frames, no missing seconds across the tab-switch moments. (Under getDisplayMedia, the stream is screen-or-window-scoped — tab switches should NOT interrupt capture. This is the empirical confirmation of D-01/D-15 amended semantics.) result: issue reported: | Three layers of evidence collected during this test:

(a) Operator UX observation: "if i open the new tab, it suggest to 'share this tab instead'" — Chrome's tab-share affordance. (b) Console errors: 3× Uncaught Error: Attempting to use a disconnected port object at offscreen:1:4644, starting at the 290 s pre-emptive reconnect mark. (c) Silent data loss in the produced archive (discovered after Test 3 was paused — user completed the save and shared smoke.sh output): smoke.sh waited 600 s before detecting the new zip; once detected, smoke.sh reported caution: filename not matched: video/last_30sec.webm. Inspecting the zip (session_report_2026-05-16_13-54-52.zip, 88 254 bytes) confirms it contains rrweb/session.json (empty), logs/events.json (empty), screenshot.png, meta.json — no video/ directory at all. severity: blocker observed_evidence: | Pre-bug (the GOOD news):

• 33+ segment rotations over ~6 minutes, "kept: 3/3" invariant holding in the OS:Recorder logs (D-13 restart-segments lifecycle live and healthy — sizes 472-799 KB per 10s segment)

The actual bug chain (most severe → least severe):

1. SILENT VIDEO DATA LOSS on save (BLOCKER — defeats phase goal):

   • Archive shipped with no video file. The phase's whole point is producing a playable last_30sec.webm — and the operator-facing save flow does NOT do that.
   • Root cause located by code reading (NOT a fix attempt) at src/background/index.ts:346-352: if (videoBufferResponse.segments.length > 0) { zip.file('video/last_30sec.webm', mergeVideoSegments(...)); } else { logger.warn('✗ No video segments to add'); // ← we hit this branch } The else-branch ships an archive missing the video file entirely, with only a warn log. This is exactly the silent-failure mode the phase set out to fix.
   • Upstream proximate cause: REQUEST_BUFFER round-trip fails to deliver a non-empty BUFFER response. Hypothesised pathway: offscreen's encodeAndSendBuffer captures portAtRequest via the CR-01 guard (recorder.ts:534), then awaits base64 encoding; if the pre-emptive 290s reconnect lands during that await, the guard at recorder.ts:597-601 correctly refuses to post on the stale port BUT also doesn't retry on the fresh port. The SW per-request listener (background/index.ts:130-167) times out silently after BUFFER_FETCH_TIMEOUT_MS=2_000, sets videoBufferResponse.segments = [], proceeds to build the empty-video archive. The 600 s smoke.sh wait suggests the operator clicked save multiple times until one REQUEST_BUFFER round-trip happened to NOT collide with a reconnect window.

2. 3× Uncaught Error after pre-emptive reconnect (MAJOR — noise + symptom of #1):

   • Locus: src/offscreen/recorder.ts:623-625 (ping interval) + :626-630 (pre-emptive setTimeout). The setInterval ping callback uses keepalivePort?.postMessage({ type: 'PING' }) — optional chaining only catches null, not a connected-but-disconnecting Port. Microtask race between disconnect() at line 628 and the teardownPortTimers() in onDisconnect at line 618 allows a queued ping callback to execute against the now-disconnected port.
   • Spacing matches PORT_PING_MS=25_000 across the post-reconnect window (errors at 11:50:10, ~11:50:40, ~11:51:00).
   • Same disconnect race almost certainly contributes to bug #1 by leaking REQUEST_BUFFER / BUFFER on the dead port.

3. Operator-side foot-gun: "Share this tab instead" (MINOR — Phase 5 hardening; documented separately as advisory gap):

   • Chrome's platform UX surfaces this button on every other tab when extension uses getDisplayMedia in tab-share mode.
   • Mitigation options: (a) operator guidance "pick Entire Screen", (b) nudge picker via video: { displaySurface: 'monitor' } constraint in the getDisplayMedia call.

4. OPR-3: SW Idle-Unload Survival

expected: | Start a new recording (run smoke.sh again with KEEP_PROFILE=1 to reuse the loaded extension; click icon to start recording). Let it record ~15 s. Then: open chrome://extensions → find Mokosh → click the "service worker" link → in the DevTools that opens, click "Force stop" on the SW. Wait 60 s (the SW should stay dead — no auto-revival). Click the extension icon → "Сохранить отчёт об ошибке". SW revives, OFFSCREEN_READY handshake re-establishes, archive downloads. Open the WebM in Chrome → video from BEFORE the Force Stop is present in the file. (Tests that the offscreen-document buffer survives SW unload — D-16/D-17 + CR-03 hasDocument fix. This is the most fragile path; if it fails, the bug is likely in getVideoBufferFromOffscreen post-respawn or in the OFFSCREEN_READY handshake re-fire.) result: blocked blocked_by: other reason: | Paused by user decision after Test 3 surfaced the port-reconnect uncaught-error finding. Routed to /gsd-debug. Test 4 deliberately not attempted yet because it would compound debug-session signal: SW Force-Stop triggers exactly the disconnect→reconnect path that's currently buggy. Re-run after debug fix lands to get a clean signal on the SW-survival contract.

Summary

total: 4 passed: 2 issues: 1 pending: 0 skipped: 0 blocked: 1

Gaps

• truth: "When the operator clicks save, the produced archive contains a playable video/last_30sec.webm derived from the ring buffer's most recent 30 s. This is the entire goal of Phase 1; without it the phase is not delivered to operators regardless of structural correctness." status: failed reason: | User reported smoke.sh waited 600 s then detected the new zip with caution: filename not matched: video/last_30sec.webm. Inspection: archive session_report_2026-05-16_13-54-52.zip (88 254 bytes) contains rrweb/session.json, logs/events.json, screenshot.png, meta.json — NO video/ directory. Code at src/background/index.ts:346-352 ships the archive without video when videoBufferResponse.segments.length === 0, only logging a warning. The empty-segments condition is reached when the REQUEST_BUFFER → BUFFER port round-trip fails. Three concrete failure modes contribute: (1) Pre-emptive 290 s reconnect race in offscreen recorder leaves encodeAndSendBuffer's portAtRequest stale; CR-01 guard at recorder.ts:597-601 correctly refuses to post BUFFER on dead port but doesn't retry on fresh port; SW listener times out silently after BUFFER_FETCH_TIMEOUT_MS=2_000. (2) Ping setInterval at recorder.ts:623-625 surfaces 3× Uncaught Error post-reconnect from the same race window — symptomatic of the same root cause. (3) saveArchive at background/index.ts:340+ has no retry-with- backoff on empty BUFFER and no operator-visible error signal — ships silently. severity: blocker test: 3 artifacts:

  • path: src/background/index.ts lines: "346-352, 430-493, 130-167" issue: "Empty videoBufferResponse.segments silently produces no-video archive; saveArchive has no retry/error-surface; per-request BUFFER listener times out without retry"
  • path: src/offscreen/recorder.ts lines: "522-545, 597-604, 606-630, 623-625" issue: "Pre-emptive 290 s reconnect race window: encodeAndSendBuffer correctly drops stale post but never re-encodes/re-posts on fresh port; ping setInterval racing with reconnect's teardownPortTimers leaves callbacks executing on disconnected port" missing:
  • "REQUEST_BUFFER retry path on offscreen side after port reconnect (re-encode + re-post on fresh port)"
  • "OR: saveArchive-side retry loop with backoff when videoBufferResponse.segments is empty"
  • "Operator-visible error: surface 'no video data — try again' in popup instead of silently shipping no-video archive"
  • "Atomic ping-callback guard (check port.connected before postMessage, or try/catch)"
  • "Test coverage in tests/offscreen/port.test.ts: pre-emptive reconnect during in-flight REQUEST_BUFFER (currently only SW-side disconnect is pinned)"
  • "Test coverage in tests/background/: saveArchive behavior under empty-BUFFER response (currently no test exists for this branch)" debug_session: ""

• truth: "Operator picking 'tab' at the getDisplayMedia picker should not be one click away from accidentally redirecting the share target via Chrome's 'Share this tab instead' affordance." status: advisory reason: | Chrome's platform UX: when an extension uses getDisplayMedia to share a tab, every other tab shows a 'Share this tab instead' button in the 'Sharing your screen' banner. Clicking it replaces the underlying MediaStream, which our onUserStoppedSharing handler treats as end-of-session. User flagged this during Test 3. severity: minor test: 3 artifacts:

  • path: src/offscreen/recorder.ts lines: "ref D-01/D-15 amended getDisplayMedia call" issue: "displaySurface preference not declared" missing:
  • "Optional: pass { video: { displaySurface: 'monitor' } } to nudge Chrome's picker toward screen-share by default"
  • "Operator documentation: 'pick Entire Screen, not This Tab'" debug_session: "" defer_to_phase: 5