Skip to content

build(workflows): increase run_affected_benchmarks step timeout#12513

Draft
Planeshifter wants to merge 1 commit into
developfrom
philipp/ci-fix-benchmarks-timeout-2026-06-03
Draft

build(workflows): increase run_affected_benchmarks step timeout#12513
Planeshifter wants to merge 1 commit into
developfrom
philipp/ci-fix-benchmarks-timeout-2026-06-03

Conversation

@Planeshifter
Copy link
Copy Markdown
Member

Description

This pull request:

  • increases timeout-minutes from 60 to 90 on the "Run affected benchmarks" step in .github/workflows/run_affected_benchmarks.yml.

Failing run: https://github.com/stdlib-js/stdlib/actions/runs/26882401036

Symptom: The action 'Run affected benchmarks' has timed out after 60 minutes. — reproduced on four distinct develop SHAs in the last seven days: d864f6f8, d2f751e2, e903f792, aac3a7c1.

Root cause: New BLAS ext/base packages are merged in batch push events. Each package adds benchmark/benchmark.js and benchmark/benchmark.ndarray.js. The runner script executes all JavaScript benchmark files serially across all affected packages. When 7–15 packages fall within a single push event window, cumulative execution time exceeds 60 minutes. The benchmarks themselves are bounded (auto-tuned iteration counts, 5-min per-benchmark cap in the bench harness); only the aggregate is over budget.

Fix: Raising the step timeout to 90 minutes covers the observed 7–15 package batches with margin.

Related Issues

No related issues.

Questions

No.

Other

Second run reference: https://github.com/stdlib-js/stdlib/actions/runs/26880759233

Note: this is a proportional fix rather than a structural one. If batch sizes grow beyond ~14 packages at current benchmark throughput, the timeout will need to increase again. Parallelizing or sharding the sequential benchmark execution would be a more durable long-term fix.

Checklist

AI Assistance

  • Yes
  • No

Disclosure

This PR was proposed by Claude Code as part of an automated CI-failure investigation routine. The root-cause analysis (serial benchmark accumulation exceeding a 60-minute step limit), the fix (one-line timeout change), and the supporting evidence (four failing run logs reviewed) were produced by Claude Code. Final review and merge decision rest with the maintainers.


@stdlib-js/reviewers


Generated by Claude Code

The `run_affected_benchmarks` job on `develop` has timed out at the
60-minute step limit on four distinct SHAs in the last seven days
(d864f6f, d2f751e, e903f79, aac3a7c). Each failure shares the same
signature: "The action 'Run affected benchmarks' has timed out after
60 minutes."

Root cause: new BLAS `ext/base` packages are merged in batch push
events. Each package contributes two benchmark files
(`benchmark/benchmark.js` and `benchmark/benchmark.ndarray.js`).
The runner script (`scripts/run_affected_benchmarks/run`) executes all
JavaScript benchmark files serially. When 7-15 packages are covered
by a single push event window, cumulative execution time exceeds
60 minutes. The benchmarks themselves are correctly bounded (auto-tuned
iteration counts, 5-min per-benchmark cap); only the aggregate is too
long.

This commit raises `timeout-minutes` from 60 to 90 on the "Run
affected benchmarks" step. At the observed batch sizes the runs were
landing just over 60 minutes; 90 provides sufficient headroom for
batches of up to ~13-14 packages at current benchmark throughput, which
covers the documented failures with margin.

Ref: https://github.com/stdlib-js/stdlib/actions/runs/26882401036
Ref: https://github.com/stdlib-js/stdlib/actions/runs/26880759233
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants