[Observation] terminal-find's failure message blames the find bar for startup-race input

[Bidthedog]

Labels

• At least one area:* label added — area:terminal and area:infra.

What happened (observed outcome)

packages/ui/tests/e2e/terminal-find.e2e.ts:147 — "finds in the scrollback, counts and steps
matches — and types nothing at the shell" — failed and passed on retry inside a full npm run gate
on master, which the strict flake gate correctly turned into a red run (353 passed, 1 flaky).

Error: expect(locator).not.toContainText(expected) failed
Expected substring: not "is not recognized"
  > 178 |       await expect(term).not.toContainText('is not recognized');

The failure message blames the find bar, and the find bar is innocent

This is the part worth acting on, separately from the flake itself.

Read the captured buffer in order:

VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
C:\…\throng-tfind-bIGj75>t't' is not recognized as an internal or external command,…
C:\…\throng-tfind-bIGj75>echo NEEDLE_A
NEEDLE_A
C:\…\throng-tfind-bIGj75>echo other
…

The stray t — and a run of 32 Vs before the first prompt — arrive before echo NEEDLE_A,
which is the test's own first command and runs long before the find bar is ever opened. So whatever
typed that t did so during app/terminal startup. It is not find-bar leakage.

The assertion cannot tell, because it is scoped to the whole terminal buffer:

await expect(term).not.toContainText('is not recognized');

Anything that ever reached the prompt fails it, and the failure then reads as "searching typed at
the shell" (SC-002) — the one thing the test exists to prove, and the one thing this run does not
show. A reader who trusts the message goes looking in the find/reserve-key path, which is clean.

Suggested fix, and it is not just a bigger timeout: scope the assertion to output produced after
the find interaction — e.g. capture the buffer immediately before find-close, and assert only on
the delta — or use a unique token per phase, the way docs/testing.md already recommends for
terminal work. That way startup noise cannot be attributed to the find bar.

What you expected (intended outcome)

The spec passes on the first attempt in a full gate run, and when it does fail, the message names
what actually went wrong.

Steps to reproduce

Load-dependent, and it does not reproduce in isolation:

Condition	Result
Inside a full npm run gate on master (serial tier, ~17 min of continuous E2E)	1 flaky — failed, passed on retry
Alone on the same master, --repeat-each=6, THRONG_E2E_RETRIES=0, --workers=1	6 passed (39.8s)

The spec is already in the serial tier (parallel-plan.json, mechanism CPU) because it makes a
shell do real work, so this is the documented starvation shape rather than a defect in the product.

Environment

• OS / version: Windows 11
• throng branch or commit: master @ e6460d10
• Elevated (admin) run? No

Evidence

It is not the #290 work that just landed

Worth stating explicitly, because this was the first full gate on master after PRs #343 and #346
merged. The same test, same line, in every full gate run available:

Run	Contains the #290 fix	terminal-find.e2e.ts:147
#343 branch gate	no	ok
#343 branch gate (2nd)	no	ok
#346 branch gate	yes	ok
#346 branch gate (2nd)	yes	ok
master, after both merged	yes	failed, passed on retry

Four full-suite passes, two of them with the fix present, plus 6/6 standalone afterwards. Nothing in
that change touches this path: it alters what a rebuilt view believes about the kitty negotiation,
and cmd never negotiates kitty, so programOwnsKeyboard is false here either way.

Related

• [Bug] Rapidly typed characters reach the terminal out of order #300 (closed) — Rapidly typed characters reach the terminal out of order. Same family: input
  racing the shell's line assembly.
• [Bug] terminal-editing-matrix: Home/End flakes on git-bash — keystrokes race the shell's line assembly #252 (closed) — terminal-editing-matrix: Home/End flakes on git-bash — keystrokes race the shell's
  line assembly.
• [Observation] terminal-start-failure-controls' layout-readability poll timed out once under load — 0/16 since #342 (open) — the other load-dependent serial-tier flake found the same day, different spec and
  different mechanism.

Maintainer agreement

• Agreed by maintainer. Contributor may proceed with a fix (full lifecycle unless trivially small).

[Bidthedog]

🤖 Claimed by a Claude Code session — work on this issue has started.

• Session: adf72ed7-1264-4b49
• Scope: gate-reliability group: terminal-find startup-race input, same terminal-startup witness gap as [Observation] terminal-start-failure-controls' layout-readability poll timed out once under load — 0/16 since #342

Another session should not start work here until a released or complete comment appears below.

[Bidthedog]

🛑 Released — the Claude Code session that claimed this issue is no longer working on it.

• Session: adf72ed7-1264-4b49
• Why: not worked; it passed in a full green gate on the Two lost-work defects behind the preferences flake family (#333, #341) #348 branch
• Where it got to / what is left: unmeasured. Note it is two concerns in one issue: the misleading failure message is test diagnostics, but input reaching the shell before it is ready is a real product question

This issue is free for another session to pick up.

[Bidthedog]

Reclassified — and why

Retitled, bug label and v1.0.0 milestone removed, now under-observation. This one needs a caveat the other two do not, so it is stated first.

This issue is two concerns wearing one number, and only one of them is an observation.

1. The failure message blames the find bar for input that arrived during startup. That is the part this issue is titled after, and it is test diagnostics: the assertion is accurate about what it saw and wrong about what caused it. No user encounters it. On its own it is a harness clarity fix, not a defect.

2. Input can reach the shell before the shell is ready for it. That is a product question, and a real one — a user typing into a terminal panel while it is still starting is the ordinary impatience case, not an exotic one. If their keystrokes are mangled or land as a command they did not mean, that is user-visible and it is a bug.

Nobody has measured (2). It has never been reproduced deliberately, no frequency has been established, and it passed the full local gate (560 E2E, 0 flaky) and the v1.0.0-alpha3 release lane. So there are no steps to hand anyone and nothing a fix could be verified against — which is what puts this under observation rather than in a milestone.

Reclassifying is not dismissing (2). The label change reflects that the issue as written cannot be acted on, not a judgement that the underlying behaviour is fine. If anything, (2) is the most interesting thing in this thread and it is currently hidden behind a title about an assertion message.

Why the milestone went. It was a v1.0.0 blocker that nobody could act on, and v1.0.0-alpha3 shipped without it.

What would change this back

• Split it. If (2) is worth pursuing, it deserves its own issue titled after the behaviour rather than the assertion — with steps, a shell flavour, and what the user sees. That issue would be a bug from the start.
• Measure (2). Type into a terminal panel during startup, deliberately and repeatedly, and record what reaches the shell at what rate. That is a reproduction a person can perform, unlike the flake this was filed from.
• Or fix (1) alone, as a small harness change: make the assertion say "input arrived before the shell was ready" rather than implicating the find bar. That closes the misleading-diagnostic half without pretending the product question is settled.

[Bidthedog]

Split: the actionable half of this issue — scoping the SC-002 assertion so startup noise cannot be attributed to the find bar — is now #352, with the fix from the body above and a v1.0.0 milestone.

This issue keeps the other half: the flake itself, which does not reproduce in isolation and stays under observation.

Deliberately not filed: "input can reach the shell before it is ready" as a product bug. Re-reading the evidence, every sighting is of the test harness typing during a starved serial-tier run — nobody has observed a person's keystrokes being mangled by a starting terminal. Writing that up as a bug would mean inventing both the reproduction and the consequence. If someone types into a starting terminal deliberately and sees it, that is a real issue and should be filed then, with what they saw.