You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Flaky: queuedHighlight composer/queue classification is not settled after one event-loop turn #408
In dependency maintenance PR #407, CI run 39105399344, macOS test shard 2/2 (attempt 1) failed one assertion in tests/queuedHighlight.test.ts: a command the composer submitted and a queued one end with the same colors → the composer path colors the command word as known at line 52. That shard otherwise reported 1,465 passed, 25 skipped and one failed. Other macOS and Linux shards and Node compatibility checks passed on the same PR. A rerun was requested; outcome must be recorded before making a flakiness claim.
The test's settle() awaits a single setImmediate after a mocked asynchronous semantic classification. The test may assume more about asynchronous scheduling/classification than the contract guarantees; that is a hypothesis, not yet a confirmed root cause. Check for actual regression caused by string-width/typings before changing the test.
Acceptance
Reproduce against current master and maintenance PR head under contention on macOS/Node 22+ and inspect exact command/semantic cache ownership.
Determine whether production classification can actually miscolor commands or whether the test is too schedule-sensitive.
Fix the real race if product behavior is wrong. Otherwise replace one-turn timing assumptions with bounded deterministic synchronization to the classification completion event; do not weaken the assertion or add arbitrary sleeps/retries as the only remedy.
Prove queued and direct composer submissions agree on command-word and argument styling, including cancellations/stale updates.
Keep tests focused and report repeated-run stability. Preserve raw shell/output semantics.
Related: PR #407 dependency maintenance, #403 separate Fish teardown race. No evidence yet that package updates introduced the failure.
v0.21: fixed in #412. It was a real production race as well as a test race: each prompt marker's shell knowledge cleared SemanticService's cache and resolved in-flight lookups as unknown, so a stored queued command whose lookup was in flight kept the unclassified color. A superseded lookup is now asked again against the new knowledge (bounded); stale answers are still never cached. The test now waits for the shell's startup knowledge and for the lookups it started instead of one setImmediate. New regressions fail on the old code; 16/16 passes in two concurrent loops. Physical check: docs/testing/v021-physical-qa.md 1.7. Not merged yet.
Activity
raiseCatError commentedon Oct 18, 2026
v0.21: fixed in #412. It was a real production race as well as a test race: each prompt marker's shell knowledge cleared
SemanticService's cache and resolved in-flight lookups asunknown, so a stored queued command whose lookup was in flight kept the unclassified color. A superseded lookup is now asked again against the new knowledge (bounded); stale answers are still never cached. The test now waits for the shell's startup knowledge and for the lookups it started instead of onesetImmediate. New regressions fail on the old code; 16/16 passes in two concurrent loops. Physical check:docs/testing/v021-physical-qa.md1.7. Not merged yet.Merge pull request #412 from raiseCatError/fix/v021-reliability