Session lifecycle tests flake under parallel load, and one flake reads as three

[aymanbagabas]

Several end-to-end tests in crates/shell-use-cli/tests/session_lifecycle.rs fail intermittently when the suite runs in parallel. Locally I see roughly one failure per three full-suite runs, each time a different test:

• a_color_query_is_answered_over_the_pty — fixed in feat: answer OSC colour queries and track dynamic colours #95 by waiting for the report rather than for the command
• expect_exit_code_timing_out_does_not_accept_a_stale_code
• open_reports_the_daemon_pid_the_child_and_readiness

All pass in isolation, repeatedly. The common shape is a readiness or completion signal that is inferred rather than observed: wait command falls back to "the prompt came back and the screen is idle" when the session has no shell integration, and an idle screen is indistinguishable from a command that has not printed yet. A loaded machine widens that window.

The one already fixed shows the pattern — the probe writes nothing until it finishes, because its queries are answered by the terminal rather than echoed, so the screen was idle for the whole run. Waiting for the line the assertion reads made it deterministic. The remaining two likely want the same treatment: wait for a definite marker instead of an inferred state.

One flake looks like three

The check matrix in .github/workflows/ci.yml has no fail-fast: false, unlike the bindings matrix below it. A single flake on one platform cancels the other two, so the pull request shows three red checks and it is not obvious which one actually failed, or that only one did.

  check:
    strategy:
      fail-fast: false   # <- the bindings matrix already sets this
      matrix:

That is a one-line change and would make these much easier to read even before the tests are made deterministic.

[aymanbagabas]

A fourth one, in the JS binding suite this time, with a fix in #99: echo roundtrip drives a real session compared getCursor() against a state.cursor captured five calls earlier, so a prompt arriving between the two reads made them differ by its width (x: 0 against x: 2 on macOS).

It is the same shape as the others — an inferred signal standing in for an observed one — and it produced a useful measurement for this issue.

I tried waitIdle as the barrier first, since the snapshot test in that file already uses it. Against a shell with a deliberately slow prompt (PROMPT_COMMAND='sleep 0.4'):

cursor right after `wait command`: {"x":0,"y":2}
cursor after `wait idle`:          {"x":0,"y":2}    <- not a barrier
cursor 1s later (settled):         {"x":2,"y":2}

So waitIdle is no more reliable than wait command here, and for the same reason: the screen is quiet because the prompt has not started. Anything in this suite currently using waitIdle to mean "the shell has finished repainting" has the same hole.

The one signal that did hold was shell integration — with it active, wait command left the cursor already settled. Which suggests the fix for the whole class is to make these waits depend on the reported prompt rather than on quiet, and to understand why integration was not in play on the CI runner that failed.