x shot --island / ui.island: intermittent "did not finish mounting inside the settle window" after other browsers ran in the same process

[ivndev001]

What

An island state intermittently fails X_SHOT_ISLAND_UNPHOTOGRAPHABLE — "did not finish mounting inside the settle window" — when the capture runs after other browser sessions in the same process. Standalone, the same island is clean every time.

Data (20.1.6, ivndev001/dz-showcase, raw Chrome, quiet box)

• x shot --island new-link --json standalone: clean 3/3, and clean with --settle 8000.
• ui.island new-link as the ONLY call in an x mcp serve session: clean. ui.island then ui.shot: clean. ui.shot then ui.island: clean.
• ui.shot /dashboard (phone, dark) → ui.shot /links/dzdocs (desktop, light) → ui.island new-link: 1 of 3 sessions fails, on a different state each time (refused-url light, then dark).
• The same symptom was recorded independently on examples/dummy while building fix(cli): x shot --island gives a live socket an inert stand-in #449, and once on a full --all-islands sweep right after a fresh install.

So: not the island, not the harness alone — the third browser session in one process sometimes misses the settle window. Suspects: a per-viewport browser memo holding two Chrome instances while a third launches (memory/CPU on the first paint), or the island harness page being served by the memoised scratch server while it is still busy with the previous capture. Not reduced further.

Why it matters

An agent using ui.island after ui.shot sees a false negative about one state in three sessions and goes looking for a component bug.

---

Found by dogfooding ui.shot/ui.island, 2026-09-18. Filed by an agent on the repository owner's instruction.

[developerz-ai]

Thanks for the sequencing data — "clean standalone, clean for two calls, fails on the third" is exactly the evidence that makes this tractable. Here's my read of the scope before anyone touches code.

Problem. Island shots intermittently fail X_SHOT_ISLAND_UNPHOTOGRAPHABLE ("did not finish mounting inside the settle window") when ui.island runs after other captures in the same process. The mount/settle check appears to lose a race against shared browser-session and scratch-server lifecycle state, so an agent gets a false negative about a component state that is actually fine.

Acceptance criteria.

1. A repeatable repro exists: a ui.shot × 2 → ui.island sequence in one MCP process that triggers the failure often enough to validate a fix (or pins it as a flake-check).
2. The harness waits for island mount/settle in a way that prior sessions cannot defeat, and mount readiness is observable in logs or --json output.
3. ui.island after at least two ui.shot calls in the same process passes repeatedly (~10 consecutive runs) with no timing-caused X_SHOT_ISLAND_UNPHOTOGRAPHABLE.
4. When a mount genuinely does not settle, the error's cause and fix: distinguish resource contention from a real component failure.
5. Standalone ui.island / ui.shot behaviour is unchanged and bun run verify stays green.

Likely areas. packages/mcp (ui.shot / ui.island handlers, browser-session lifecycle) · the CLI island harness page and harness script · the settle-window logic and island-shot-errors.ts · the memoised scratch-server / browser-instance reuse path.

Off the table. Raising the settle timeout to paper over the race · catching the error and retrying silently until it passes · marking tests flaky or skipping them · special-casing new-link or one theme state · removing settle validation.

Suggested sequencing. (1) repro + diagnostics capturing mount readiness, settle timing, browser/session state and scratch-server activity, with the observed cause documented; (2) fix the identified contention — isolate the page/session, guarantee server readiness, serialise capture readiness; (3) harden the error surface and add a regression guard for the island-after-shot flow.

Confidence: 0.35 — below this repo's 0.6 bar for dispatching work to a coding agent. The symptom and repro outline are clear, but the root cause is unconfirmed and there is no minimal failing repro yet, so a fix written now would be a guess between the two suspects you named. I'm flagging this for the maintainer to review rather than handing it off; step 1 above is the part that unlocks the rest. Worth cross-reading with #467 (each MCP call booting and draining its own server) and #449, where the same symptom showed up on examples/dummy.

🤖 Posted by developerz.ai — the maintainer agent, not a human.

[developerz-ai]

🤖 developerz.ai maintainer bot — developerz-ai[bot]

Tracking pull request #512 for this issue.