Add: per-worker timeline to the parallel wall-time assertion

[ChaoWao]

Makes the next occurrence of #1496 self-diagnosing. No behaviour change, no threshold change.

Why

test_parallel_wall_time fails on macOS CI in ~2% of runs (4 of 218 sampled ut (macos-latest, 3.10) jobs; 0 of 101 on Ubuntu) with a total of 0.49-0.57 s against a 0.203 s Linux median (max 0.204 s over 7 runs). That is near-serial, not a marginal threshold.

But the assertion reports only the total, which cannot separate the two shapes:

• the parent was descheduled between its three sequential dispatch() calls, so w1/w2 started a full sleep period behind, or
• every worker was dispatched on time and finished late.

Those are different bugs. The total is identical either way.

What

Record each worker's dispatch and completion offset and include them — plus the visible CPU count — in the failure message. Verified by temporarily tightening the threshold:

AssertionError: expected parallel wall time < 0.48s (serial would be 0.60s), got 0.20s
  cpu_count=320 affinity=320
  w0: dispatched +0.1ms, done +200.6ms, w1: dispatched +0.1ms, done +200.6ms, w2: dispatched +0.1ms, done +204.5ms

On Linux all three dispatch at +0.1 ms and finish together — the healthy shape. On the next macOS failure the same line says which worker started late, and the question in #1496 is answered from the CI log alone.

sched_getaffinity is Linux-only, hence the guard. cpu_count() alone can overstate what a container actually lets the process run on, and the runner's real width is one of the unknowns #1496 could not close.

What this deliberately does not do

It does not touch the assertion. #1496 asks explicitly that the threshold not be relaxed and no retry be added: at 0.49-0.57 s against 0.203 s, something is serialising three processes that are each only in time.sleep(0.2). A wider bound would make the symptom disappear and leave the cause running.

This is the same approach as #1501 for #1489 — when a failure is rare and cannot be reproduced on demand, the highest-value move is to guarantee the next natural occurrence yields the evidence, rather than spending exclusive hardware or CI time trying to force one.

Verification

• pytest tests/ut/py/test_hostsub_fork_shm.py -q → 6 passed.
• Failure path exercised by temporarily tightening the bound (output above), then restored.
• pre-commit clean.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@ChaoWao, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b7593955-97d5-43e4-8448-7fcff3a2ba09

📥 Commits

Reviewing files that changed from the base of the PR and between 22f2d53 and 9208eff.

📒 Files selected for processing (1)

• tests/ut/py/test_hostsub_fork_shm.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ChaoWao]

Superseded by #1509.

This PR existed to instrument the wall-clock failure message so the next macOS CI failure could be diagnosed blind. With a macOS box now available, the failure is traced to time.sleep over-sleeping under load (measured 0.2 s → 0.24–0.31 s under taskpolicy -b + contention) — not a code defect, and not reproducible on bare metal. So the wall-clock assertion is dropped outright (and the no-wall-clock-proxy principle codified in docs/testing.md) rather than instrumented. Closing in favor of #1509.