Repository navigation
ci: give e2e/timed its own shard so shard 3 fits the step cap - #4771
Merged
Merged
Conversation
Behavior-preserving cleanup of debt introduced by last week's merges (#4763, #4762, #4740, #4722, #4741). - booking-web hand-rolled two partial HTML escapers while `escapeHtml` already existed in the backend. Move it to `@core/util/escape-html.util` so both callers share one implementation. - Collapse five copy-pasted `html.replace` calls for superseded base meta tags into one pattern list, dropping the reassigned `let html`. - `autoEffectiveTimeZone` returned the browser zone from both arms of its `isUtcLikeTimeZone` guard. Drop the dead branch and the two pass-through wrappers (`applyDayjsDefault`, `getStoredBrowserTimeZone`). - The welcome step guard probed sessionStorage three times and tested set membership twice, with one branch unreachable. One probe, one check. - Derive the event-form date key unions from the key lists instead of keeping hand-maintained `Set<string>` literals in sync with them. - Resolve the view zone and civil day once per day-column scan instead of once per timed event. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzeokDYpEzrNDZeYkA1DzW
The timezone and parity work added e2e/dst, e2e/event-form and e2e/parity and grew e2e/timed to 46 tests, all on shard 3. That leg reached 6m06s of its 8 minute step cap on main and then timed out twice in a row, on this PR and on its merge-queue run, both at 64 of 67 specs passed with zero failures. Measured locally, e2e/timed is 3.2m of that load and dst, event-form and parity together are 1.8m. Give timed a leg of its own and move the other three to a new shard 5: scaled to CI that is about 3m54s and 2m12s, in line with shards 1 (3m53s) and 2 (2m34s), and it drops the e2e critical path from the 8m cap to about 3m54s. The step cap stays at 8 minutes and no test changes. The required check is the `e2e` gate, which aggregates the whole matrix, so adding a leg needs no branch-protection change; e2e-shards.test.ts still proves every e2e directory lands on exactly one shard. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzeokDYpEzrNDZeYkA1DzW
tyler-dane
added
the
agent-automerge
Claude
tyler-dane
enabled auto-merge
October 23, 2026 11:12
Contributor
Author
|
Measured on this PR's own e2e run, which exercised the new five-leg matrix end
Both came in about 1.3x my estimate, which scaled from a local run, and shard 5 Headroom on the critical path goes from 0-24% (6m06s-8m00s of 8m) to about 39% Generated by Claude Code |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #
What and why
No issue: found by the weekly technical-debt sweep, which hit this problem
head-on while landing #4770.
e2e-shard (3)runse2e/timed e2e/dst e2e/event-form e2e/parityagainst atimeout-minutes: 8step cap. The timezone and parity work of the last weekadded
e2e/dst,e2e/event-formande2e/parityand grewe2e/timedto 46tests, and all four landed on shard 3. It is now the critical path by a wide
margin and close enough to the cap to fail at random:
47703fb(main)On #4770, a diff that touches no spec and no test helper, shard 3 went:
Two timeouts in four runs, every one at the cap with zero assertion failures.
That ejected the PR from the merge queue once and cost four extra shard runs.
It is not specific to that PR: any PR that reaches the shards gets the same
coin flip.
The change
Measured locally,
e2e/timedis 3.2m of shard 3's load (46 tests) anddst+event-form+paritytogether are 1.8m (21 tests). Sotimedgets a leg toitself and the other three move to a new shard 5. Scaled to CI that is about
3m54s and 2m12s, in line with shards 1 (3m53s) and 2 (2m34s) as measured on
the merge-queue run, and it drops the e2e critical path from the 8m cap to
about 3m54s.
The workflow already anticipated this: "the shard legs can change count
without touching branch protection" and "Resize by moving directories between
lists". The required context is the
e2egate, which aggregates the wholematrix via
needs.e2e-shard.result, so a fifth leg needs nobranch-protection change.
What this deliberately does not do:
timeout-minutes: 8step cap is unchanged. Raising it would hide theproblem rather than fix it.
just across two legs.
packages/scripts/src/testing/e2e-shards.test.tsstill proves everye2e/directory with specs lands on exactly one shard, and it passes. I also checked
that nothing else hardcodes the shard count: only
docs/CI-CD/workflows.mdsaid "four shards", updated here.docs/CI-CD/ci-audit-2026-09.mdis left alone as a dated historical record.Verify
bun test packages/scripts/src/testing/e2e-shards.test.ts2 pass / 0 fail,bun test:scripts:fast224 pass / 0 fail,bun lintpassed(semantic-colors, agent-constraints, todo-copy, prosemirror-dedupe, biome).
This PR's own
e2erun is the real check: it exercises the new five-legmatrix end to end.
The branch carries a merge of
mainbecause #4770 squash-merged while thisfollow-up was being prepared; the diff against
mainis the two files above.Generated by Claude Code