Repository navigation
ci: the CSMS log was captured on a red job, never on a red row - #54
Conversation
The capture added for #52 was conditioned on `if: failure()`, which misses the one case it exists for. A parallel FAIL whose isolated retry passes is a FLAKE: `standingOf` calls it "ok", `endsTheBuild` is false, the sweep exits 0 and the job is GREEN. The `CALLERROR -- InternalError` worth explaining happens inside exactly that. Of 34 archived SteVe sweeps, 20 carried a red row, and almost all of them were green jobs -- so the first shape would have captured nothing on the overwhelming majority of the runs it was written for. The trigger is now a red ROW, read from results/summary.md, with the job's own status kept for the failures that never get as far as writing one. Still silent on a clean sweep: that half of the first shape was right -- megabytes nobody reads, in an artifact downloaded in bulk when mining the archive. Exercised against real archived summaries rather than reasoned about: a flaked sweep with a green job CAPTURES, a clean sweep SKIPS, and a run with no summary at all and a failed job CAPTURES. The row grep matches 23 of the 23 archived summaries that contain a `(flake)`. `if` rather than `&&` for the grep, because the default shell is `bash -e` and a bare compound ending non-zero would abort the step on the ordinary no-match case -- which would have turned "nothing to capture" into a red step. Follows up #52, whose other half -- the retry no longer overwriting the wire log it adjudicates -- is unaffected.
|
Warning Review limit reached
Next review available in: 27 minutes Limit details: You’ve used all 1 included review currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
1 participant
The CSMS log capture added for #52 was conditioned on
if: failure(), and thatmisses the one case it exists for.
The hole
A parallel FAIL whose isolated retry passes is a flake:
standingOfcalls it"ok",endsTheBuildis false, the sweep exits 0, the job is green. TheCALLERROR -- InternalErrorworth explaining happens inside exactly that.Of 34 archived SteVe sweeps, 20 carried a red row — and almost all of them
were green jobs. So the first shape would have captured nothing on the
overwhelming majority of the runs it was written for, and the absence of a
csms-*.logwould have read as "there was nothing to capture".The fix
Trigger on a red row, read from
results/summary.md, with the job's ownstatus kept for the failures that never get as far as writing one. Still silent
on a clean sweep — that half of the first shape was right: megabytes nobody
reads, in an artifact downloaded in bulk when mining the archive.
Exercised, not reasoned about
Run against real archived summaries from the corpus:
The row grep matches 23 of the 23 archived summaries containing a
(flake).ifrather than&&for the grep: the default shell isbash -e, so a barecompound ending non-zero would abort the step on the ordinary no-match case —
turning "nothing to capture" into a red step.
Scope
Workflow only,
e2ejob.tests/gate-parity.shcovers thecheckjob and isunaffected;
bun run verifypasses in full. #52's other half — the retry nolonger overwriting the wire log it adjudicates — is untouched and already on
main.Follows up #52.