test: adaptive cancellation assertion races before partial transition
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 75/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- testing
Research direction
Start with tests/browser-adaptive-exploration.test.ts, especially the failing assertion around line 444, and run npm run test:browser-accessibility-oracles to reproduce the race. Trace the partially failed action and cancellation timing, then synchronize cancellation with the intended in-flight action state rather than a fixed 250ms delay. Done means the bounded non-replayable evidence assertion passes deterministically without weakening the production evidence contract.
Written by the indexing model from the issue text.
Description
Problem
The full adaptive browser gate can deterministically fail the test cancellation during a partially failed action retains bounded non-replayable evidence because its fixed 250ms abort fires before any error transition is recorded.
Reproduction
npm run test:browser-accessibility-oracles
Observed repeatedly on current origin/main plus PR #2099:
✖ cancellation during a partially failed action retains bounded non-replayable evidence
AssertionError: assert(failed)
at tests/browser-adaptive-exploration.test.ts:444
The result is already incomplete/cancelled, but result.transitions.find((transition) => transition.status === \"error\") is undefined because cancellation wins the timing race before the intercepted repeat action reaches its expected partial failure.
Expected
The test should synchronize cancellation to the intended in-flight action state instead of using a fixed wall delay, then assert bounded non-replayable evidence deterministically.
Scope
Test synchronization only unless investigation shows runtime cancellation dropped an already-observed transition. Do not weaken the production evidence contract.
- Dominant language
- TypeScript
- Stars
- 17
- Forks
- 4
- Avg merge
- 1h 37m
- Merged PRs (30d)
- 45
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Automattic/wp-codebox
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Automattic/wp-codebox#2531 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Automattic/wp-codebox#2467 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Automattic/wp-codebox#2466 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Automattic/wp-codebox#2105 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Automattic/wp-codebox#2061 ·
Maintainers usually reply within 1 day
All issues in Automattic/wp-codebox
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Doist/todoist-cli#576 ·
Maintainers usually reply within 1 day
-
🐛 Bug supabase/cli
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
CopilotKit/aimock#491 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
agilepathway/label-checker#710 · 2 comments ·
Maintainers usually reply within 1 day