fix(device): recover persistently overloaded iOS video decoders#24224

Approvability

Verdict: Approved at 3ea9f07

Macroscope's review found this PR approvable — This is a focused iOS decoder recovery fix that preserves normal and Android paths while adding bounded handling for repeated overloads. The production change is small, uses existing fallback/error mechanisms, and has targeted regression coverage.

^{You can add or adjust custom eligibility rules. Learn more.}

Review in Change Stack →

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Addressed both CodeRabbit findings in eb250e7be2c6d97033fdc4278de75b8d1eb56908.

• Video-only decoder failures: recoverDecoder() now stops the Duo feed and reports an immediate error for both the decoder error callback and a thrown decode() call. Regular iOS feeds retain MJPEG fallback and their input connection.
• Recovery after software decoding: 120 decoded frames now clear the backlog count on either decoding path. Software selection is tracked separately and remains selected. A later isolated overload reconnects for a fresh keyframe using software; another overload before recovery still reaches the bounded fallback/error.

Added six focused cases, including normal-feed controls. Four failed on the previous commit for the reported symptoms; all 34 tests across the three focused stream/AVC files now pass. vp run check:changed also passed format, lint, both knip passes, seven affected package typechecks, and adjacent tests. The PR description now reflects the final behavior and distinguishes the earlier Electron harness evidence from these review regression tests.

thanks @floklein. your bounded recovery keeps the fresh-keyframe retry, tries software after repeated overload, and preserves input while falling back to mjpeg or reporting a duo/simlock error.

updated this branch directly, preserving your three commits and merging current main without rebasing. simplified the software configuration and consolidated duplicate no-mjpeg cases into the existing recovery table, including simlock recovery after 120 healthy frames. the cleanup removes 32 lines; no recovery behavior was dropped. head: 1c03910c4d51d768bb5b18582d74ce41a4d0ef6f.

verification passed:

• reproduced the regression on current main: the existing repeated-backlog test fails because the third decoder does not request software.
• blacksmith: all 36 focused stream/avc tests pass. vp run check:changed passes format, lint, both knip checks, seven package typechecks, and adjacent stream tests.
• two independent read-only code reviews found no issues at this head.
• system chrome ran the production shared transport with native video encoding/decoding, synthetic h.264, and injected overload on the default decoder. main kept reconnecting (eight subscriptions); this head used three subscriptions, selected software once, and continued decoding. the home input packet was delivered in both runs. these are controlled recovery checks, not live-device performance measurements.

unverified: an actual ios host and integrated device panel, packaged electron, native mobile, relay/tunnel, real overloaded hardware, and live duo/simlock. the vm has no ios host. android/webrtc and sps configuration are unchanged. all 29 ci checks passed on the pushed head; the pr is mergeable.

before, current main, matching synthetic input:

main repeatedly reconnects with unchanged decoder configuration

after, production transport on this head:

software decoding stabilizes after three subscriptions and input still sends

ten-second comparison of injected backlog recovery, main left and candidate right

Verified in a real dev environment

result: unverifiable for the changed decoder behavior on this linux boat vm. no code changes or pushes.

read the description, discussion and full diff. the pr is open; its five commits are by floklein and maria. checked out exact head 1c03910c4d51d768bb5b18582d74ce41a4d0ef6f after attempting the baseline on github/main (6575ce32508bd7908444241f3719aa33aaf77f90) in /home/user/main.

ran vp i for both revisions and their real dev servers sequentially, in the background. drove /usr/bin/google-chrome using the repository's playwright dependency. created projects pointing at the real checkouts, created threads and submitted real codex gpt-6.1-sol turns through the composer. the candidate displayed device verification ready.; its native provider log reports a completed turn with no error. no mocked streams, fixtures, replay provider or decoder injection were used.

opened the device surface and enabled the device hub in both versions. both report iOS Simulators need macOS with Xcode. candidate settings lists only local simulators, with no remote device source configured. checked the neighboring check again and cancel/reopen flows; they remain responsive.

short runtime transcript (pairing credentials omitted):

main device prerequisite, after adding a real checkout project and sending a real provider turn:

main device setup reports the missing macos ios host

candidate, same setup flow and prompt:

candidate device setup reports the same missing macos ios host

candidate real codex gpt-6.1-sol response in the web client

candidate device setup, check again and cancel in the real app

Not verified

the original repeated ios decoder backlog could not be reproduced on main, and the fix could not be exercised on the candidate. this vm is linux, has no xcrun/xcode, and has no configured remote ios host. a real ios avcc stream is required to verify fresh-keyframe retries, software selection, recovery after 120 frames, mjpeg fallback, and preserved simulator input. these screenshots and recording prove the prerequisite blocker, not decoder recovery.

also unverified: live duo/simlock failure behavior, packaged electron on windows/macos, native ios/android clients, relay/tunnel, and device streaming on android. installing an android emulator would not exercise this ios-only change. no local checks were rerun because no code changed; existing ci is green and is not treated as live verification.

startup note: the root checkout initially defaulted to ~/.t3; it was stopped immediately and restarted with explicit --home-dir /home/user/t3code/.t3 before candidate browser interactions.

@maria-rcks To reproduce this, you need an iOS simulator running on a Mac with Xcode, then view its Device stream in T3 Code from a different machine. My original setup was the simulator on my Mac and the T3 Code Electron client on Windows.

The Linux VM can act as the viewer, but it needs a connection to the Mac environment hosting the simulator. Opening the local Device setup on the VM alone cannot exercise this bug. The before/after verification needs that real remote iOS stream under sustained animation.

Update: I reproduced this today without the fix, with no injected overload. The client was Windows Electron on nightly 97e35bcf (12 commits behind 6575ce32, no device-related paths changed, same Electron 44.10.0), viewing an iPhone 18 Pro Max simulator (iOS 27.2) on the Mac, with a React Native app showing a continuous full-screen animation.

Over 385 seconds, the decoder closed 8 times, each at queue 9, and each time a new AVCC stream opened about 1 second later on the same default decoder. It never tried software decoding.

This is less frequent than the original capture (11 reconnects in 39 seconds) and comes in bursts, with gaps from 3 to 178 seconds. The setup differs (simulator, app screen, unfocused second app window), so that doesn't show main improved.

With the fix: same Mac simulator, same app screen, same second-window setup. The web client was built from nightly 97e35bcf plus this PR's commits, so stream.ts is identical to the PR head 95a259de and those commits are the only difference from the run above. I confirmed the loaded chunk contained the fix.

The fix did what it's meant to: two closures at startup, then it switched to software decoding and stayed there. Software decoding isn't a complete cure, though: one more closure at queue 9 happened at 89 s, and that reconnect kept prefer-software. There was no MJPEG fallback after the first stream started.

This is one run each, and the bug is bursty, so it's a good sign rather than proof. The two runs also weren't identical: for about 330 s of the fix run, a second window was viewing the same simulator on the unfixed nightly, and the window had focus for about the first 300 s. I can't confirm whether that second viewer was present during the run without the fix.