Skip to content

Fix the Windows CI timeout in custom_agent_is_typable_when_running_in_the_current_workspace - #2874

Open
sinelaw wants to merge 1 commit into
masterfrom
fix-orchestrator-custom-preset-flake
Open

Fix the Windows CI timeout in custom_agent_is_typable_when_running_in_the_current_workspace#2874
sinelaw wants to merge 1 commit into
masterfrom
fix-orchestrator-custom-preset-flake

Conversation

@sinelaw

@sinelaw sinelaw commented Jul 31, 2026

Copy link
Copy Markdown
Owner

e2e::plugins::orchestrator_new_dialog::custom_agent_is_typable_when_running_in_the_current_workspace times out on Windows CI (180s, seen on #2865 and unrelated to that branch — it dates to the test's introduction in 5c99886).

What happens

nextest's kill dumped the stuck screen:

│  Agent: [custom…  ▼]
│╭─ Agent Command ─────╮
││ ▸ [zcustomcmd     ] ││

The test types zzcustomcmd; the box holds zcustomcmd. One leading character is gone, so wait_until(contains("zzcustomcmd")) never fires, and wait_until is unbounded.

Why

Picking custom… paints the label on the selector right away, but applyAgentPreset (orchestrator.ts:6698) re-renders the form and then hands focus to cmd via setFocusKey/snapFormFocusTo — a plugin round-trip. The gate was wait_until(contains("custom")), which is already satisfied during that window, so the test typed while focus was still on the dropdown.

Probing the window directly confirms it:

PROBE pre-type contains(custom)=true focus=Some("│▸ Agent: [custom…  ▼] │")
PROBE no-wait:  ││ ▸ [zcustomcmd ] ││     <- the CI string, reproduced locally

Linux and macOS pass only because the one tick_and_render inside wait_until happens to complete the round-trip before the first keystroke. Windows' slower plugin thread does not.

Fix

Gate on the focus marker leaving the selector rather than on the label. With that gate the same reproduction yields zzcustomcmd.

focused_line can't be used in a wait_until condition — it asserts exactly one on screen, and a frame mid-handoff legitimately has none — so this adds a focused_line_opt sibling returning None in that case.

Not addressed

The same race exists in the real editor: pick custom… and type instantly on a loaded machine and the first character goes to the dropdown. Closing that needs the focus handoff to be synchronous with key handling, which the plugin can't do from its side — separate work.

Verification

  • All 27 orchestrator_new_dialog tests pass
  • cargo fmt --check clean; no new clippy warnings on the changed lines

🤖 Generated with Claude Code

`custom_agent_is_typable_when_running_in_the_current_workspace` timed out
on Windows CI after 180s. The nextest kill dumped the stuck screen: the
command box held `zcustomcmd` where the test had typed `zzcustomcmd`, so
the `wait_until` for the full string could never fire.

Picking "custom…" paints the label on the selector immediately, but
`applyAgentPreset` hands focus to the command box through a plugin
round-trip that lands a tick later. The gate was `contains("custom")`,
which is already true during that window — so the test typed while focus
was still on the dropdown and the leading character went nowhere. Linux
and macOS passed only because the single tick inside `wait_until`
happened to complete the round-trip before the first keystroke; Windows'
slower plugin thread did not. Typing straight after the arrow key with no
wait at all reproduces the exact CI string locally.

Gate on the focus marker leaving the selector instead. `focused_line`
can't serve as a `wait_until` condition — it asserts exactly one marker,
and a frame mid-handoff legitimately has none — so this adds a
`focused_line_opt` sibling that returns `None` there.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant