Repository navigation
test(acpmux): start-mode answers don't leak between test files - #22158
Conversation
startMode.ts keeps acpmux's answers in module memory, read from storage once per page. Two test files cleared localStorage but not that memory, so in one bun process new-tab-composer-first-frame failed whenever access-chip-pending-warning ran first (an inherited 'no mode here' answer hid the access chip). Both now reset the module through a test seam, as modelCatalogHost's resetModelCatalogForTests does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Passes: CI passes on CI passes on Written by red: cmux-next checks (god files, concurrency, crash safety, l10n); no finished base run on 88d14fb to compare; do not merge until green; see lane-rules
Tour of |
|
Found 11 test failures on Blacksmith runners: Failures
...and 1 more test failures. View all on Blacksmith
|
[Low impact] The PR appears safe to merge. SummaryPrevents start-mode answers from leaking between the two test files.
Reviews (4) · Last reviewed commit: "Merge remote-tracking branch 'origin/fea..." · Reviewed by Greptile |
|
Bead |
…de-test-isolation
…de-test-isolation
…de-test-isolation
|
|
|
Review (subagent, correctness first): SHIP at 45d6df7 No blocking findings. resetStartModesForTests clears the cached answers and bumps the snapshot version without dropping live subscribers; production never calls it. It follows the existing reset*ForTests seams in webviews. Risk tier: normal (agent review plus checks; no high-tier paths touched). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Shipped in:
|
new-tab-composer-first-frame.test.tsxfails wheneveraccess-chip-pending-warning.test.tsxruns before it in the same bun process. Whether a shard goes red then depends on file order.startMode.tskeeps acpmux's start-mode answers in module memory, which it reads from storage once per page. Both test files clearedlocalStorageafter each test but not that memory. So the first-frame test inherited an earlier file's answer that this folder starts with no mode, and its access chip never drew. The first-frame file's own cleanup also wrote that same answer for the next file. Both files now reset the module throughresetStartModesForTests(), a test seam likemodelCatalogHost'sresetModelCatalogForTests(). App behavior doesn't change.Testing
On huge-blue with bun 1.4.2, from
webviews/:bun test test/access-chip-pending-warning.test.tsx test/new-tab-composer-first-frame.test.tsx4b5c7ad9: 11 pass, 1 fail ("a new chat paints its last effort and its kept start mode on the first frame…").14da28ca: 12 pass. The reverse order also passes 12/12.bunx tsc --noEmit -p .is clean.Observed / Not run
Changelog
none
🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need.Summary by cubic
Fixes a test-ordering flake where
new-tab-composer-first-frame.test.tsxfailed whenaccess-chip-pending-warning.test.tsxran first in the same bun process.startMode.tskeeps acpmux start-mode answers in module memory, read from storage once per page. Both test files clearedlocalStoragebut not that memory, so the first-frame test inherited the earlier file's answer and its access chip never drew. Both files now reset the module throughresetStartModesForTests(), a test seam likeresetModelCatalogForTests(). App behavior doesn't change.Testing
bunx tsc --noEmit -p .is clean.Written for commit 75ef674. Summary will update on new commits.