test_gap_cron_cronjob races a per-second cron against a fixed 10s deadline, inside pr-gate's scope #10581

test_gap_cron_cronjob races a per-second cron against a fixed 10-second wall-clock deadline, then asserts the ticks happened:

job.start();
const tickDeadline = Date.now() + 10_000;
while ((ticks < 2 || autoTicks < 2) && Date.now() < tickDeadline) {
  await new Promise((resolve) => setTimeout(resolve, 100));
}
job.stop();
auto.stop();

console.log("manual ticked at least twice:", ticks >= 2);
console.log("auto ticked at least twice:", autoTicks >= 2);

The deadline is a timeout, not a barrier: when it expires first, the loop exits and the fixture prints false for lines it is expected to print true for. That is a parity_fail, not a timeout — so it reads as a compiler regression.

The header comment says the output is "deterministic despite the timing". That holds only while two ticks of a * * * * * * schedule land inside ten seconds. On a loaded machine they need not.

Why this one matters more than the usual flaky fixture. It carries the test_gap_ prefix, so it is inside the gap shards that pr-gate actually runs — unlike test_parity_* / test_issue_* fixtures, which ride in the snapshot ungated. It is also absent from test-parity/gap_snapshot.json, i.e. expected to pass. A slow or contended runner can therefore redden a merge with it.

It has already cost real work. It failed in a merge-queue validation and #10530 was held out of a train on the strength of it. The author's --trace llvm A/B then showed byte-identical IR, and the fixture confirms why: its only statement-position user call is main() at line 49, which is async and so never an inline candidate — everything else is console.log, native job.start()/stop(), or arrow callbacks passed as arguments. A change confined to inline_calls_in_stmts' statement arm cannot reach this program at all.

The same host produced the same shape elsewhere the same night: test_issue_1140_buffer_index_runtime, a ~1.6 s fixture, took five minutes and failed in the sweep, then passed 20/20 standalone on both arms with byte-identical output. Load average was 19-47.

Suggested fix — make the assertion independent of wall-clock luck, in either direction:

• wait on the tick condition with no deadline and let the harness's own timeout be the failure mode (a timeout is classified distinctly from a parity mismatch, so it would not read as a miscompile); or
• keep a deadline but scale it to what is being asserted (two ticks of a one-second schedule needs far more headroom than 10 s under contention); or
• assert on what was observed — print the tick count's own liveness (ticks > 0) and let a separate, non-gated fixture cover the "at least twice" timing claim.

Filed from the merge-queue lane while attributing gap reds for merge train 215.