Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug][CI]: shard duration table is three weeks stale and under-weights 678 unrecorded test files

Closed Beginner friendly
  • Is something wrong?
#6,982 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
bun, github-actions, typescript
Domain
ci-cd, testing

Research direction

Read scripts/ci/run-bun-test-batches.sh and the refresh instructions for scripts/ci/test-durations.tsv; inspect the table’s header and scripts/ci/test-durations.ts for how durations are parsed. Use the documented command to refresh the table from a recent green run. Done when the table reflects that run and the issue’s described shard balancing problem is addressed; the issue calls for a full dispatch to check the result.

Written by the indexing model from the issue text.

Description

bug platform
Client or integration

Other

GitHub Actions shard balancing (scripts/ci/run-bun-test-batches.sh reading scripts/ci/test-durations.tsv), not an installed client.

Area

Platform (Windows / macOS / Linux)

Summary

The per-file duration table that every sharded CI lane uses to balance its shards has not been refreshed since it was introduced. It was generated once from Linux run 35816902207 (#5653, 2026-09-23) and holds 1,558 rows, while the suite now selects 2,236 files. The 678 files without a row each weigh the table median, 157 ms.

On macOS those unrecorded files average roughly 0.7 s each, so the balancer under-weights them about fourfold. In the last full dev dispatches the two macOS shards were both predicted at 683 s yet differed by up to about 190 s within the same run (for example 1082 s vs 873 s in run 38104436843, 885 s vs 1063 s in run 38050525359). The unrecorded files alone cost 184-289 s per macOS shard on 2026-10-11/12 versus 115-220 s on 2026-10-04/05, and that share grows with every new test file.

This contributed to #6978, which is being addressed separately by adding a third macOS shard. The table refresh is the cheap remaining lever, but it changes Linux 4-shard and Windows 9-shard membership as well, so it should be its own change with its own full dispatch.

Expected: the table is refreshed from a recent green run with the documented command, and refreshed again when the share of unrecorded files grows large, so predicted and actual shard times stay close.

Reproduction
  1. head -4 scripts/ci/test-durations.tsv shows # Source: run 35816902207, Linux test 1/4-4/4; git log -- scripts/ci/test-durations.tsv shows one commit (0144cba8fc, 2026-09-23).
  2. Any macOS shard log from a recent lane=all dispatch on dev prints Predicted shard time from recorded durations: 683s; a file without a record weighs 157ms for both shards.
  3. Parsing those logs with parseJobLog from scripts/ci/test-durations.ts shows the actual per-shard time and the time spent in files missing from the table, as quoted above.
Version

dev a0191a1b6fd921a6e5a9d12cb123c8df88b023e7

Operating system

GitHub-hosted macos-latest, ubuntu-latest, windows-latest

Provider and model

Not applicable.

Logs or error output
Shard 1/2: 1113 files in 116 primary Bun processes (scope all, batch size <= 12, timeout 300s).
Predicted shard time from recorded durations: 682s; a file without a record weighs 157ms and a batch closes before 150000ms.

(run 38104436843, macos 1/2; its measured test time was 1082 s, macos 2/2 873 s)

Screenshots and supporting files

No response

Redacted configuration

No response

Checks
  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
5h 7m
Merged PRs (30d)
617

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.