Problem/Motivation
OfferStepperTest::testTheGestureFinishedAfterTheAnswerStillReachesTheServer pins a real and narrow behavior: a quantity typed while a request is out, and finished with from inside that request's own answer while Drupal is still working through the command queue, still reaches the server. The test holds that window open on purpose, because a loaded runner does it by accident.
It asserts the outcome first and its own precondition last: waitForHeld() runs before the assertion that Drupal really was still busy when the gesture was finished with. So a failure cannot tell apart the two things it could mean:
- the window was open and the typed quantity was genuinely lost, which is the regression the test exists to catch
- the window was never open, so the test measured nothing, which is a fault in the test rather than in the code
Both report the same sentence, "Failed asserting that 1 is identical to 2". A run that misses the window is indistinguishable from a run that catches a bug, which is the worst property a test of a race can have.
Proposed resolution
Record what the setup did as it happens, and assert it in that order, before the outcome: what the answer found in the field, whether the gesture was finished with at all, whether Drupal was still busy at that moment, and what value was committed. Each assertion carries the whole trace, and the held quantity is asserted last, as the one thing left that can be wrong.
Count the requests that leave after the commit as well. A gesture that never reaches storage fails in two ways worth telling apart: nothing left, so the queue never sent it, or something did and the server did not hold it.
Already done elsewhere
This issue was filed after several intermittent failures on CI, and it originally proposed closing a race in the setup too: the number was typed from a zero-delay timeout, which a loaded runner starves for longer than the answer takes to arrive, so the typing happened after the window it is about. That is fixed in #3616584: Judge the orphan rule against the seats a booker could actually take, which landed the same day: the number is now typed inside the ajaxSend handler itself. The failures that prompted this issue were all on branches that predate it.
What is left is the half above, which the fix does not address: when this test does fail, it still says nothing about which half broke.
Remaining tasks
Review.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
None: test-only.
AI-Generated: Yes (Claude Code read the CI logs across several pipelines, identified the assertion order that makes this test undiagnosable, drafted this issue summary and wrote the change in the merge request. I reviewed both. The change is test-only and its own correctness is what CI reports.)
Issue fork yoyaku-3616605
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mably commentedComment #5
mably commented