e2e: slot5-closeout-qa:107 misses the provisional pick when the measured search lands first (test-only race)

Open Beginner friendly
  • Is something wrong?
#1,055 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
playwright, typescript
Domain
testing

Research direction

Read slot5-closeout-qa.spec.ts around line 107 and the related #211 acceptance-2 step. Update the test to accept either engrave-recommendation or engrave-pick-measured, and assert the provisional sentence only when the rule block is visible. Run the affected e2e spec repeatedly; it should pass whether the background search finishes before or after the check.

Written by the indexing model from the issue text.

Description

bug test

Symptom. The full e2e on m1-follow 65ba8e4a1 (2026-11-07, shard 2, card env) failed one test: slot5-closeout-qa.spec.ts:107 › visual QA: Engrave panel — stock, labels, tool recommendation and depth-coloured preview — expect(getByTestId('engrave-pick-provisional')).toBeVisible({ timeout: 60_000 }) → element(s) not found.

Not a code defect: the window is real but transient. engrave-pick-provisional is rendered only while measuredStatus === 'measuring' AND the rule's reference block (measuredNow === null && rec) is the one on screen. Once the background search lands, engrave-pick-measured replaces the whole block and the provisional span is gone; for the same job fingerprint the store's kept rule never returns the status to measuring, so the 60 s poll cannot recover. The failure screenshot shows exactly that state: measured: a1 measured, “Use the recommendation”, “Chosen by simulation: 98 % fidelity…” — and no engrave-recommendation/engrave-pick-provisional anywhere in the snapshot.

Same sha, isolated: 3/3 pass (18.5 s / 12.7 s / 12.0 s, --repeat-each=3, own port), with measuring candidates 1 of 1… / 1 of 2… visible each time. The earlier full run on 66e181f09 passed the same spec in 9.8 s. So it is a load/timing race in the test's own steps (screenshot + fold-open + two expects) against a background search that can finish first on a busy machine.

Suggested fix (test-only). The fresh-state intent is “the panel offers a cutter at once, and the answer moves once the search lands” — the test already tolerates either offer for the PRESS (engrave-use-recommended or engrave-use-measured). Make the read before it tolerant the same way: poll for engrave-recommendation OR engrave-pick-measured, and only assert the provisional sentence when the rule block is the one on screen (its absence is now a legitimate state, not a failure). The later #211 acceptance-2 step already re-reads the rule box after the job changes, so it stays honest.

Not blocking: it is pre-existing (the spec file is untouched by #1047/#1050/#1051) and does not gate the M1 tray work.

Dominant language
TypeScript
Stars
2
Forks
0
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SlyWombat/CaseMaker

All issues in SlyWombat/CaseMaker

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.