fix(test): bfs_latency_v3 smoke flake — bump iterations + decouple from gate verdict (#792) - #793
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Sorry @robotrocketscience, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
|
[claim:review:jojo:2026-05-14T16:15:44Z] |
With --queries 4 --iterations 2, the smoke produces 8 samples per arm. nearest-rank p95 with n=8 resolves to the max sample, so a single noisy timer reading determines the entire percentile — and on GitHub Actions runners sharing CPU with neighbours, the slowest sample can spike to 700-1100ms, blowing the 50ms delta_p95 gate and tripping the test's 'assert rc == 0'. Raising to 10 iterations gives 40 samples per arm; p95 lands at the 38th-largest sample, so a single outlier no longer determines the verdict. Bumping warmup 1→2 stabilises the first-sample cold path (HRR + BM25F cache build). Local pytest-3.13 runtime: 0.66s → 16.7s. Still smoke-scale — acceptable defence against the recurring CI flake documented in issue #792.
…shape (#792) The file docstring says: 'Latency numbers are not asserted — only schema, determinism, and gate-result shape.' But the assertion 'assert rc == 0' contradicts that — rc encodes gate.passed which is a latency assertion. The dedicated test_evaluate_gate_* fixtures above already cover gate logic with hand-rolled ArmResults; the smoke's job is the CLI plumbing. Change: - assert rc == 0 → assert rc in (0, 1) - add shape assertions on payload['gate']: delta_p50_ms, delta_p95_ms, tail_ratio types numeric; *_pass keys all bool. - cross-check rc encoding: '(rc == 0) is gate.passed' — flake cannot decouple the two without something more interesting going wrong. This matches the stated test intent and survives any future GitHub-runner noise event without re-blocking PRs. Belt-and- braces against the n=8 → p95=max-sample race fixed by the prior commit.
9cd16e6 to
b2287ef
Compare
Review — approvingTargeted defence-in-depth on the bench-smoke flake. Both halves are necessary and sufficient:
The Two atomic commits, both SSH-signed; +23/-6 in one file; discretion grep on rebased diff clean; CI all green on the rebased SHAs ( Minor nit (not blocking): the new shape assertion enumerates Labeling |
|
merge-train: merged b2287ef → |
|
[release:review:jojo:2026-05-14T16:21:03Z] |
Closes #792
Two atomic commits unblock the
pytest (3.13)smoke flake that's been silently blocking PRs (most recently #790).Root cause
test_main_end_to_end_smokecallsmain([... "--queries", "4", "--iterations", "2", "--warmup", "1", ...])→ 8 timed samples per arm._percentileuses nearest-rank semantics; with n=8 the p95 index resolves toceil(0.95*8) = 8= max sample. Sop95 = p99 = max_sample, and a single noisy timer reading on a shared CI runner trips thedelta_p95 ≤ 50msgate. The test then trips onassert rc == 0.The file docstring already declares the intent:
But
assert rc == 0is precisely a latency-numbers assertion. Defence in depth fixes both halves.Commit 1 — bump iterations 2→10, warmup 1→2
40 samples per arm → p95 = sample[37], no longer max. Local pytest-3.13 runtime: 0.79s (no measurable regression; the earlier 16.7s was a cold-venv build, not the test itself).
Commit 2 — decouple smoke from gate verdict
assert rc == 0→assert rc in (0, 1)(both = harness ran end-to-end and emitted JSON).payload["gate"]: every key is present, numeric values are numeric,*_passkeys are bool.(rc == 0) is gate["passed"]so a flake can't decouple the two without something more interesting going wrong.Dedicated
test_evaluate_gate_*fixtures above already cover gate logic deterministically with hand-rolledArmResultobjects — gate verdict is not the smoke's job.Verification
uv run --python 3.13 pytest tests/test_bfs_latency_v3.py -q→ 11 passed in 1.10s.Co-Authored-Bylines per repo convention.github/main: CLEAN.Out of scope
GATE_DELTA_P50_MS,GATE_DELTA_P95_MS,GATE_MAX_OVER_MEDIAN_RATIO) — those are the real benchmark's contract for ≥1000-sample runs._percentilesemantics — nearest-rank is correct at production sample sizes.