test(curl): widen the monitor wait slack to survive a loaded CI runner

[Guikingone]

Follow-up to #890 / #1002.

curl_monitor_excludes_write_callback_cpu_from_network_wait failed on four unrelated pull requests in one afternoon — #1011 (an ir_lower release-ordering change), #1012 (array_fill argument boxing), #1017 and #1019 (test-only additions). None of them touches curl, the monitor, or timing. Each cleared on a re-run.

The measurement is still doing its job; the slack is what does not survive a shared runner. The control stayed at ~0.42 ms every time while the instrumented run came back at:

5 560 376 ns
7 802 876 ns
9 111 124 ns

against WAIT_SLACK_NS = 5_000_000.

That is loopback scheduling jitter, not billed callback CPU — the burn is ~130 ms, so billed CPU shows up as ~130 ms, which is exactly what the defect reported (133.9 ms against a 1.2 ms control).

20 ms covers the observed values with better than 2x to spare and still leaves ~6.6x below the 132.7 ms gap the defect produced. The test keeps failing outright on the regression it guards — two orders of magnitude is not a threshold anyone has to tune — while no longer failing on the machine it runs on.

Nothing else changes. BURN_ROUNDS, the total > 20_000_000 floor that rejects a fixture too short to measure anything, and the after_wait > 0 control that rejects a build recording no network wait at all are all untouched, so neither of the two ways this test could pass vacuously is widened.

Opened as its own PR rather than folded into one of the four it was blocking: it is your fixture, and the margin is a judgement call you may want to make differently.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KSAAWPyNBq6dP2b5puN3wr

[greptile-apps]

Greptile Summary

This PR makes the curl monitoring regression test resilient to loaded CI runners while preserving its ability to detect callback CPU incorrectly billed as network wait.

• Raises the permitted loopback scheduling jitter from 5 ms to 20 ms.
• Adds a fixture guard requiring CPU nested inside curl_exec() to exceed twice the tolerance.
• Leaves the existing total-duration and nonzero-network-wait checks intact.

Confidence Score: 5/5

The PR appears safe to merge; the previously identified risk of masking the regression has been addressed by the new nested callback CPU guard.

No actionable new issue remains. The previous finding was manually resolved after the author added a guard ensuring the measured nested CPU duration remains substantially larger than the widened tolerance.

Important Files Changed

Filename	Overview
tests/codegen/curl/monitoring.rs	Widens the network-wait tolerance and adds a callback-duration assertion that prevents the regression test from becoming vacuous.

_{Reviews (3): Last reviewed commit: "test(curl): assert the burn outweighs th..." | Re-trigger Greptile}

[Guikingone]

Two more data points for this, both from #1066 — a PR that touches __rt_str_to_int and nothing on the curl monitoring path:

run 1:  control 372625 ns → in-callback 7815417 ns
run 2:  control 432417 ns → in-callback 7418999 ns   (a re-run of run 1's failed job)

The 7.80 ms in this PR's comment is run 1. What is new is run 2: the job was re-run and reproduced. So on the current macos-aarch64 runner this is not an occasional flake that a re-run clears — it is reliable, and it is blocking unrelated PRs from ever going green. The control stayed sub-millisecond both times, and both samples sit ~18x below the 133.9 ms the defect produced.

That makes this PR the unblock rather than a tidy-up.

[nahime0]

20 ms is fine