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

Command icon 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

mably created an issue. See original summary.

mably’s picture

Title: The gesture-after-the-answer browser test fails intermittently, and says nothing about which half broke » Make the gesture-after-the-answer test say which half broke when it fails
Issue summary: View changes

  • mably committed c2f3e8fb on 1.x
    fix: #3616605 Make the gesture-after-the-answer test say which half...
mably’s picture

Status: Active » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.