Repository navigation
Dev /__rsc_shell endpoint should own a TOTAL response deadline (client fetch bound becomes a plain liveness backstop) #720
Description
Follow-up named in the #716/#717 fetch-bound work: devShellFetchTimeoutMs currently reconstructs the server's worst-case timing from a model of the endpoint's internals (probe + 2×budget + retry margin) — fixed once in #716 after the model omitted the 10s pre-flight probe, but the pattern stays error-prone: any new sequential step inside the endpoint silently invalidates the client formula. Deeper fix: the endpoint (the operation's owner) bounds its own total deadline and ALWAYS responds within a known envelope (MISS/404 on internal timeout); the client fetch timeout becomes a fixed generous liveness backstop, not a function of server knobs. Refs: #716 simplify notes, shell-build-manifest.ts comment.
Activity
ivogt commentedon Jul 7, 2026
Cross-check from #719 (fix/ppr-dev-stability): confirmed this is the server-side half of the same long-poll refinement. #719 added the client half — the endpoint tags its transient boot-race branches (dep re-optimization, missing runners, empty registry — the capture-realm boot NOT covered by the existing
await s.discoveryDoneroute-discovery gate at router-discovery.ts:1131) withx-rango-shell-dev: NOT-READY(503), and the read-through bounded-re-polls that signal (150ms interval / 10s deadline). This issue's 'endpoint owns a total deadline and ALWAYS responds within a known envelope' is exactly the move that subsumes it: the endpoint awaits its own readiness internally (up to the bound) and responds once, collapsing the client's 150ms poll into a single held request and reducingdevShellFetchTimeoutMsto a fixed liveness backstop. NOT-READY isn't named in the issue text only because #719 introduced it after this was filed.ivogt commentedon Aug 30, 2026
The client still reconstructs the endpoint envelope (
devShellFetchTimeoutMsinsrc/rsc/shell-build-manifest.ts: probe + 2× captureTimeout + margin). That formula is pinned next to the endpoint's actual sequential steps, and #719 already owns the boot-race half (x-rango-shell-dev: NOT-READY+ bounded re-poll).The deeper "endpoint owns a total deadline; client is a fixed liveness backstop" move is real but unscheduled — any new sequential step inside
/__rsc_shellstill has to update the client formula. Reopen when rewriting the endpoint.