Stop a click made while a request is out from being lost under CI load

OfferStepperTest::testClickDuringTheRequestSurvives goes red intermittently on CI and has never once been reproduced locally. It asserts that a second click, made while the first request is in flight, is not lost: two units held. On a red run one is held.

What is already ruled out. Two fixes were tried in 3616893 and neither is the cause. Widening every wait, to more than twenty seconds, changes nothing. Clicking synchronously inside ajaxSend made it worse, because ajaxSend is dispatched from inside the queue's own send, before the queue has recorded that a request is out: a click there finds an idle queue and schedules a second dispatch, which is the very race the test polices. A microtask has the ordering right and the starvation gone, and the test still fails.

The sibling test that holds the page busy on purpose passes, and its timeline shows the queue behaving correctly throughout: refusing to dispatch for as long as the page is busy, then posting the moment it frees. So the queue is not dropping anything, and no wait is too short.

Two dead ends worth recording. The job artifact does not help: browser output captures the server response, not the live DOM, so for a JavaScript-driven test every capture shows the page as delivered. And the machine here will not reproduce it: twenty five consecutive instrumented runs of the test alone, twenty five green, plus five runs of the whole class and a dozen more under deliberate contention.

How this gets answered. The test carries a probe recording the things that tell the remaining hypotheses apart, at the moment each answer arrives: whether the second click registered at all and what the field became, how many requests left, what each answer said, whether the field was focused, and what maximum came back. Whether the field was focused is the one that matters most, because the catch up that resends a click the answer did not carry is skipped while the visitor is in the field.

Since it only happens on CI, it is sampled on CI: run-tests.sh takes a single method through --class Class::method and repeats it with --repeat, and the other jobs are skipped, so one pipeline is twenty samples of one test rather than one sample of everything.

AI-Generated: Yes (Claude Code diagnosed what has been ruled out, built the probe and drafted this summary; I reviewed it before posting.)