fix(benchmarks): log iteration start and failure in runBenchmarkWithIterations - #45432
fix(benchmarks): log iteration start and failure in runBenchmarkWithIterations#45432MajorLift wants to merge 1 commit into
runBenchmarkWithIterations#45432Conversation
The loop reported only on success, so a failed iteration incremented `failedRuns` silently and a hanging one emitted nothing at all. A stalled run, a run whose iterations all failed, and a run that stopped after the first were identical in a CI log. That is currently blocking attribution on chrome-webpack-userJourneyTransactions, where run 31423339197 carries one iteration's report and then 31 minutes of silence before cancellation, with no way to tell whether iteration 2 began. `runBenchmarkWithIterations` had no unit coverage; the three tests added here are the first. Verified both arms: 7 passed with the change, and 3 of those 7 fail with runner.ts at base while the four pre-existing tests are unaffected.
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
Builds ready [78e465d] [reused from 5fa8bb1]
⚡ Performance Benchmarks (Total: 🟢 7 pass · 🟡 10 warn · 🔴 4 fail)
Bundle size diffs
|
Changelog
CHANGELOG entry: null
Description
runBenchmarkWithIterationsemits output only on success. A failed iteration incrementsfailedRunsand returns silently; a hanging iteration emits nothing at all. So a run that stalled, a run whose iterations all failed, and a run that stopped after the first iteration are indistinguishable in a CI log.This is blocking attribution on
chrome-webpack-userJourneyTransactions, cancelled at its 30-minute timeout in 11 of the last 12mainruns. In run 31423339197 the log carries one iteration's report at 19:25:26 and then 31 minutes of nothing before cancellation at 19:56:07. Whether iteration 2 started cannot be recovered from what is emitted today.This commit adds an iteration-start line before each iteration and a failure line carrying
result.error.Verification
runBenchmarkWithIterationshad no unit coverage; the three tests added here are the first. Both arms were run:The three failures on base are exactly the three new tests, and the four pre-existing tests pass in both arms.
This does not fix the stall, and does not claim to — the stall does not reproduce on demand, so no test here exercises it. The three cases in
test/e2e/benchmarks/utils/runner.test.tscover exactly one property: an iteration that previously emitted nothing now emits a line, in the success, failure and never-returns cases.Not in this PR
The linked issue also covers two adjacent gaps in the same area, deliberately left out to keep this reviewable: the S3 key omits
run_attemptso re-runs overwrite their own objects, andsend-to-sentry.tssets no run or attempt identifier. Both are one-line additions and can follow.Related issues
Fixes: #45431
Manual testing steps
yarn jest test/e2e/benchmarks/utils/runner.test.tsmainrun, confirmchrome-webpack-userJourneyTransactionslogsiteration 2/5 startedbefore the silent period.Pre-merge author checklist
Note
Low Risk
Adds console logging and unit tests only; does not change benchmark execution, retries, or result aggregation.
Overview
Makes stalled or failed benchmark iterations attributable in CI logs. Previously
runBenchmarkWithIterationsonly logged on success, so a hang looked identical to an iteration that never started.Adds a start log before each iteration and a failure log with
result.error. Includes unit tests covering start announcements, failed iterations, and attributing a hang to the iteration that began but never finished.Reviewed by Cursor Bugbot for commit 78e465d. Bugbot is set up for automated code reviews on this repo. Configure here.