fix(site-editor): pick the content backend from the v8 marker; v7 never waits
Part of the v8 Studio stack (base: #7796). v8 Fast Preview + Localhost track, on top of #7872. PO decisions of 2026-10-11.
R1: v7 sites behave as on main. R4: a v8 sandbox session uses the daemon's content protocol. The site editor now picks its content backend from the project's Blocks v8 marker (#7871) instead of waiting on probes for every site.
What
selectContentBackend (components/sections-editor/content-backend.ts) gets isV8Project:
| v8 project (marker) | v7 project (no marker) | |
|---|---|---|
Waits (pending)? | Yes, until its backend answers. It never shows the v7 editor first | Never: legacy right away, as on main |
Stored deco serve connection | Used (Localhost) and wins | Ignored: useDecoServeConnection reads as none |
cms session | GitHub backend, i.e. the hosted draft (R3) | Legacy. In flagged orgs one background probe still runs, and only a v8 answer (an upgrade branch) switches it |
| Sandbox session | Waits for the working tree and the daemon's /_sandbox/rpc, then uses the protocol (R4). An older daemon (404), a v7 tree or an error falls back to legacy | Legacy. The same background probe rule applies |
| Probe retries | 2, plus a 5 s re-poll on error | 1, with no re-poll, so there is no repeated 503/404 loop |
/site-editor(account-less) counts as v8: only a v8deco serveanswers it.- This closes the OPEN note in
selectContentBackend(a v8 sandbox showed the v7 editor until the probe answered). - Versions and Site tokens are shown only for v8 sites (
hostedCmsAvailable(flag, isV8)). A v7 site never shows them and never waits on the flag for them.
R1 notes
On a v7 project, backend.kind is never pending, so the v7 editor shows right away with no wait on org settings or the GitHub probe. The probe runs only in flagged orgs, tries once in the background, and never re-polls.
Tests
content-backend.test.ts: a decision table.- v7 is never pending across every flag × runtime × probe combination, ignores a stored connection, and switches only on a v8 answer behind the flag.
- v8: Localhost wins; a cms session waits and then uses the protocol; a sandbox session waits for the daemon and then uses its protocol, falling back on 404, v7 or error.
hostedCmsAvailablegates Versions and Site tokens.
use-content-backend.test.ts: GitHub and daemon detection decide the same marked or not once settled.backgroundProbeRetryshows v7 has no refetch loop after a 503 and v8 re-polls.tsc --noEmitforapps/web, oxlint, and biome format are clean. 152 test files undersections-editor,thread,main-panel-tabs,hooks,views/virtual-mcpandroutes, each run in its own process, all pass.
Stack
v8 Fast Preview track: previous: #7872 · next: #7874
Review fixes (86bdfbec0)
- v7 (no marker) is always legacy, as on main. It runs no GitHub or daemon probe (
contentProbesEnabled) and never switches backend mid-session.backgroundProbeRetryis removed. A v7 site that upgrades to v8 gets the marker once the upgrade reaches main. - v8: a failed probe (a GitHub 5xx, or the daemon restarting) is now
unavailableand keeps retrying instead of showing the v7 editor. Only a confirmed v7 answer, or the flag being off, falls back to legacy. - v8 ignores a tunnel saved from the v7 Advanced → Local.
- Tests: v7 stays legacy for every combination, including a probe that would answer v8, and v7 runs no probe. A v8 probe error is unavailable.
The table above still describes v7 "switching on a v8 answer". That no longer happens.
🤖 Generated with Claude Code