Repository navigation
[Bug]: preview_resize outlives the broker deadline and evicts a live desktop host #16764
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web (desktop preview host) and apps/server (preview automation broker)
Steps to reproduce
- Run T3 Code Nightly
0.0.46-nightly.20261005.2702(cfa4f765) on macOS with the desktop app open and connected as the preview automation host. - From an agent thread,
preview_navigatea background tab (the reply hadvisible:false). - Call
preview_resizewith{ "mode": "freeform", "width": 1440, "height": 900 }. - Immediately call
preview_click,preview_wait_fororpreview_snapshot.
Expected behavior
The resize either finishes or returns a resize timeout within the request budget. The desktop host stays registered, so step 4 runs on the same tab.
Actual behavior
Step 3 fails with Preview automation resize timed out after 15000ms. At the same moment the broker evicts the desktop host. Step 4 calls fail with No preview automation host is available … Do not retry. The desktop stays open and re-registers about one second later, so a preview_open on the same tab ~3 s later works. Every thread sharing the host is affected.
Server trace timeline (UTC, 2026-10-07):
- 07:12:44.601 resize starts
- 07:12:59.605
PreviewAutomationBroker.disconnect - 07:12:59.640–.649 click, waitFor, snapshot fail with "No preview automation host"
- 07:12:59.689 the desktop's resize reply arrives, after eviction
- 07:13:00.615
PreviewAutomationBroker.connectsucceeds
No process restarted, the Mac did not sleep, and the environment id matched throughout.
Likely cause
The desktop resize handler starts a full 15 s viewport wait after setup and after the server resize request, then performs rollback. The broker's own 15 s deadline is already running, so it expires first and treats the late reply as a dead host:
- Resize handler: https://github.com/pingdotgg/t3code/blob/cfa4f765/apps/web/src/components/preview/PreviewAutomationHosts.tsx#L595-L667
- Eviction on an unanswered request: https://github.com/pingdotgg/t3code/blob/cfa4f765/apps/server/src/mcp/PreviewAutomationBroker.ts#L614-L621
- Automatic re-register after 1 s: https://github.com/pingdotgg/t3code/blob/cfa4f765/packages/client-runtime/src/rpc/client.ts#L275-L282
Suggested fix: bound the viewport wait and rollback by the remaining request budget, so the desktop answers before the broker deadline. The no-host error could also say the host may be reconnecting, since "Do not retry" is wrong in this case.
Related: #12898 (same eviction pattern triggered by preview_wait_for), #8257.
Activity
juliusmarminge commentedon Oct 7, 2026
Note
Grok responding on behalf of Julius.
Triage: bug confirmed. Related to #12898 but not a duplicate. PR #12899 alone won't fix it.
Root cause (at
cfa4f765)apps/web/src/components/preview/PreviewAutomationHosts.tsx:595-667: theresizecase first runs the serverresizeRPC insiderunBrowserViewportMutation. Only after that does it callwaitForRenderedViewport(..., input.timeoutMs ?? request.timeoutMs)(~L627-639), which gets a fresh, full budget. If that times out, thecatch(~L640-666) sends a second rollbackresizeRPC before it rethrows. So the worst-case reply time is setup + RPC + 15s + rollback RPC.apps/server/src/mcp/PreviewAutomationBroker.ts:614-621: the broker'sEffect.timeoutOption(timeoutMs)(default 15 000 at L477) started when the request was queued. When it expires,disconnect(clientId, queue, true)evicts the host ("An unanswered request invalidates this connection"). Every thread on that host then gets "No preview automation host" until the client re-registers about 1s later.Proposed fix
waitForRenderedViewportonlydeadline - now - margin(for example 1–2s reserved for rollback and transport). Bound the rollback too, so the host always replies withPreviewAutomationTimeoutErrorbefore the broker deadline. The same audit is worth doing for other handlers that chain RPCs before an inner wait.resizeareplyGraceMslike the one fix(server): keep preview hosts that report a waitFor miss at the deadline #12899 adds forwaitFor. Better still, separate a "late but alive" reply from a dead host so a timeout alone doesn't evict a connection that is still heartbeating.packages/contracts/src/previewAutomation.ts). That's misleading while the host is reconnecting, so mention a transient reconnect.Relation to #12898 / #12899
preview_wait_forlands its miss right at the deadline. Here the host's resize path overruns its budget by design.replyGraceMs, but onlywaitForpasses it (PREVIEW_WAIT_FOR_REPLY_GRACE_MS = 1_500).resizekeeps a grace of 0, so this issue is unchanged. Even with a grace, viewport wait + rollback RPC can go past 1.5s. Track this separately, or widen fix(server): keep preview hosts that report a waitFor miss at the deadline #12899 to cover resize and add the host-side budget.Workaround
preview_resizeon a background/hidden tab (visible:false). The viewport never renders there, so the wait always runs the full 15s. Bring the tab to the foreground first.preview_status/preview_openagain (the host re-registers), even though the error says "Do not retry".juliusmarminge commentedon Oct 7, 2026
Obsolete since #15328: the resize readiness wait that overran the broker deadline was removed with the desktop automation host. Host eviction on a timeout is tracked in #16921.