Automattic / Automattic/wp-codebox
test: adaptive cancellation assertion races before partial transition
- Dominant language
- TypeScript
- Stars
- 16
- Forks
- 4
- Avg merge
- 59m
- Merged PRs (30d)
- 131
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
```bash
npm run test:browser-accessibility-oracles
```
Observed repeatedly on current `origin/main` plus PR #2099:
```text
✖ 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.
Contributor guide
No contributing guide indexed for this repository
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.
Assessment
- Tech stack
- typescript
- Domain
- testing
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 75/100