[BigSimmo]

User description

Requested by Josh · project thread

Summary

Before: every merge to main took 36 to 40 minutes of CI before Railway would deploy, because "Wait for CI" waits for the slowest job, and the tablet browser leg ran the whole tablet suite on one runner. On main run 38053471704 it hit the 30-minute global timeout with 345 tablet tests never run. A ready PR took about 14 minutes, set by one unbalanced Production UI shard (521s of tests against 401s and 346s). A frozen unit coverage partition on #3450 held its run to the 20-minute job cap.

After: tablet splits into four legs and desktop Safari into three, so every tablet test now runs and the slowest release leg drops from ~35 to ~13 to 17 minutes. The three Production UI shards are rebalanced to 422/426/420s, about 1.5 minutes off every ready PR. The unit test step stops at 13 minutes instead of 20 when a batch freezes.

How: the tablet timing table comes from the per-test durations in that tablet leg's log; files the leg never reached carry the mobile-webkit cost and are marked as estimates until a tablet release-ui-timings report replaces them. Production UI profiles are re-measured from the three shard logs of PR run 38101082169, with four files moved. Every test still runs once, on one worker, zero retries, same per-test timeouts.

Areas touched: Delivery and assurance

Verification

• Checks run: npx vitest run tests/playwright-pr-shards.test.ts tests/playwright-release-shards.test.ts tests/ci-*.test.ts → Tests 247 passed (247); check:diff-integrity PASS (17 -> 17 test cases); check:github-actions and check:ci-scope passed; node scripts/playwright-pr-shards.mjs --validate → PR UI shard parity OK: 46 production specs across 3 groups. Full suite left to CI.

Risk and rollout

• Risk: low. Workflow and shard-grouping only. Main pushes book 4 more runners for the report-only browser matrix (21 legs, was 17). Tablet estimates could leave a leg lighter or heavier than planned; each leg is far under the 30-minute cap either way.
• Rollback: revert this commit.
• Provider or production effects: None. The main-push saving appears once a merge runs the new matrix.

Notes

• Non-UI merges (where UI was never proved on the PR) still run the full Chromium suite on one release leg (~28 min); splitting that is a possible follow-up.
• Many PR runs are cancelled by bot "fix:" commits (Qodo pushed three in 20 seconds on Remove on-screen example-data notices, tidy spacing, match Work header pill to Clinical #3450), each restarting the clock.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JoxhPS6iT7SYdBZeSR1w1S

---

Generated by Claude Code

---

Summary by cubic

Cuts CI wall-clock time on merges and PRs by splitting the slowest browser legs, rebalancing the PR UI shards, and failing a frozen unit batch sooner.

The tablet release leg ran the whole suite on one runner and hit the 30-minute global timeout with 345 tests never run, holding Railway's "Wait for CI" for ~35 minutes on every merge. It now splits into four legs (~12 minutes each) and desktop Safari into three (~13 minutes), so every tablet test runs and main finishes in roughly 13–17 minutes instead of 36–40.

The three Production UI shards drifted to 521s/401s/346s of tests, with the heaviest setting every PR's wall clock. Re-measured timings and four file moves bring them to 422/426/420s, trimming ~1.5 minutes off each ready PR.

The unit test batch with partial coverage now fails at 13 minutes instead of 20 when a partition freezes; tests already have 30-second timeouts, and nothing is skipped or retried.

Migration

• Main pushes now book four more runners for the release browser matrix (21 legs, was 17).
• Tablet timings for files the timed-out leg never reached are marked as estimates from mobile-webkit until a tablet release-ui-timings report replaces them.

^{Written for commit e970c11. Summary will update on new commits.}

---

CodeAnt-AI Description

Shorten CI waits and ensure tablet browser tests complete

What Changed

• Tablet browser tests now run across four jobs, and desktop Safari tests across three, so tablet checks can finish instead of timing out with tests left unrun.
• Production UI checks are redistributed to reduce the slowest PR test group by about 1.5 minutes.
• Frozen unit test runs now stop after 13 minutes instead of waiting for the 20-minute job limit.

Impact

✅ Shorter release waits
✅ Complete tablet browser test runs
✅ Earlier failure for frozen unit tests

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: e1d3cba6-4982-4cb9-8adb-db86249a2ac9

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

---

_{Comment @coderabbitai help to get the list of available commands.}

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[codeant-ai]

🏁 CodeAnt Quality Gate Results

Commit: e970c116
Scan Time: 2026-10-11 02:23:24 UTC

✅ Overall Status: PASSED

Quality Gate Details

Quality Gate	Status	Details
Secrets	✅ PASSED	0 secrets found
Duplicate Code	✅ PASSED	0.0% duplicated
SAST	✅ PASSED	No security issues
Bugs	✅ PASSED	Rating S: No bugs
IAC	✅ PASSED	No IAC issues

View Full Results

[gitar-bot]

Gitar has auto-approved this PR (configure)

[codspeed]

Merging this PR will not alter performance

⚠️ 2 benchmarks spent significant time in system calls

System calls cannot be consistently instrumented, so they are not included in the measure, which understates the real cost. Please switch to the Walltime instrument to accurately measure system calls.

Measurement and system calls

• answer-ranking: rankAnswerEvidence 40 results
• catalog-search: rankCatalogRecords 400 records

ℹ️ 1 benchmark has no flame graph

The flamegraph could not be generated because too much time was spent in runtime internals, making the visualization not useful for performance analysis.

• medication-entities: medicationEntityMatchesInText

✅ 8 untouched benchmarks

---

_{Comparing claude/faster-ci-jrpl0u (e970c11) with main (37e070c)}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Reviewed your PR	e970c11	Oct 11, 2026 · 02:08	02:12

[codeant-ai]

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[greptile-apps]

BigSimmo has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[claude]

Claude encountered an error after 2s —— View job

---

I'll analyze this and get back to you.

[gitar-bot]

CI failed: The required 'PR required' aggregate failed only because every upstream job was cancelled (no real job failures), most likely from a newer push superseding the run or a manual cancel; this is not a code breakage and is unrelated to the PR's changes.

Overview

One unique error template was analyzed from 1 log (commit e970c11). The 'PR required' aggregate job reported that all upstream checks were cancelled, with no genuine failing job. The result is a cancellation rather than a test or build failure.

Failures

Required aggregate red due to cancelled upstream jobs (confidence: high)

• Type: infrastructure
• Affected jobs: 114366111455
• Related to change: no
• Root cause: The aggregate check reported "CANCELLED with no failing job" covering changes, static-pr, safety, coverage, ingestion-sast, build, Playwright Next build, production-ui-critical, production-ui, lighthouse-budget, and db-reset-verify. This is consistent with a newer push superseding the run (cancel-in-progress) or a manual cancellation. The PR modifies ledger data and documentation, and nothing in the log connects those changes to the cancellation.
• Suggested fix: Check for a newer 'PR required' run on the PR's current head SHA and use its result if present. If no newer run exists, re-run the workflow so the required checks complete, rather than merging past a cancelled check.

Summary

• Change-related failures: None identified.
• Infrastructure/flaky failures: 1 cancellation-driven aggregate failure (superseded or manually cancelled run).
• Recommended action: Confirm whether a newer 'PR required' run exists for the head SHA; if not, re-run the workflow. Do not treat the cancelled aggregate as a merge-ready signal.

Code Review ✅ Approved 1 closed / 1 findings

🟡 Medium risk · Shortening the unit-test job cap and repartitioning browser legs could prematurely fail slow CI jobs, delaying merges or deployments.

Splits the tablet release leg into four and desktop Safari into three, and rebalances the Production UI PR shards, so CI no longer waits on a single slow runner. The leg-count balance test now pins webkit and tablet counts, addressing the finding that it still expected webkit at 2 legs and skipped tablet.

Auto-approved: No blocking issues found.
Please see Auto-approve Docs for details on setting custom approval criteria.

✅ 1 closed

✅ Quality: Leg-count balance test still pins webkit at 2 legs and skips tablet

📄 tests/playwright-release-shards.test.ts:113-125 📄 .github/workflows/ci.yml:2000-2014
The keeps the committed leg counts within the measured balance test still checks webkit: [2, 20], and its comment still says "webkit 2". It has no entry for tablet. The matrix now runs webkit on 3 legs and tablet on 4, so nothing checks the counts the PR actually commits to. If the tablet estimates drift, or a big spec lands, a leg could approach the 30-minute global timeout this PR is fixing, and no test would fail. The tables currently give about 13.0 min per webkit leg and 11.9 min per tablet leg. Update the expectations to match the new matrix.

Review coverage

🤖 Auto-approval Approved

📋 Rules No rules evaluated

🧪 Functional validation Not enabled · Set up

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[gitar-bot]

Gitar has auto-approved this PR (configure)

[qodo-code-review]

PR Summary by Qodo

Shorten CI with balanced browser shards and an earlier unit timeout

⚙️ Configuration changes ✨ Enhancement 🧪 Tests 🕐 20-40 Minutes

AI Description

• Split tablet and desktop Safari release runs to reduce the slowest main-branch CI leg.
• Rebalance Production UI shards using recent timings to shorten PR checks.
• Fail frozen unit-test steps sooner and update checks for browser-matrix coverage and shard
 balance.

Diagram

graph TD
  PRProfiles["PR timing profiles"] --> PRLegs["PR UI shards"] --> Completion["CI completion"]
  ReleaseTimings["Release timings"] --> Selector["Shard selector"] --> ReleaseLegs["Release browser legs"] --> Completion
  UnitStep["Timed unit step"] --> Completion

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use Playwright's native test-count sharding

• ➕ Avoids maintaining per-file duration tables.
• ➖ Test counts do not account for expensive specs, so the slowest leg may remain the bottleneck.

2. Generate shard timings dynamically from CI artifacts

• ➕ Could keep allocations current as test durations change.
• ➖ Adds artifact availability and synchronization dependencies to CI scheduling.

Recommendation: Keep the committed duration-based grouping: it reuses the existing release selector, preserves deterministic file coverage, and directly targets the measured bottlenecks. Replace the marked tablet estimates with tablet timing reports after a complete run.

Files changed (5) +151 / -56

Enhancement (1) +71 / -0

playwright-release-shards.mjsAdd tablet costs for duration-based release sharding +71/-0

Add tablet costs for duration-based release sharding

• Adds a tablet timing table so the existing release shard selector can partition tablet specs. Marks costs borrowed from mobile WebKit for files the timed-out tablet run did not reach.

scripts/playwright-release-shards.mjs

Tests (2) +7 / -5

ci-browser-matrix-coverage.test.tsAssert the expanded release browser matrix +3/-3

Assert the expanded release browser matrix

• Updates matrix expectations from 17 to 21 jobs and pins the new desktop Safari and tablet leg counts.

tests/ci-browser-matrix-coverage.test.ts

playwright-release-shards.test.tsVerify tablet partition coverage and new leg balance +4/-2

Verify tablet partition coverage and new leg balance

• Includes tablet in existing release-shard coverage checks. Updates the committed balance limits to reflect three desktop Safari legs and four tablet legs.

tests/playwright-release-shards.test.ts

Other (2) +73 / -51

ci.ymlExpand release browser legs and cap the unit-test step +20/-3

Expand release browser legs and cap the unit-test step

• Changes desktop Safari from two to three legs and tablet from one to four in the release matrix. Adds a 13-minute timeout to the unit coverage step so a frozen partition fails before the job's 20-minute cap.

.github/workflows/ci.yml

playwright-pr-shards.mjsRebalance Production UI shard assignments +53/-48

Rebalance Production UI shard assignments

• Refreshes per-spec duration estimates from a recent PR run and moves four specs between the three Production UI groups. The revised groups target nearly equal measured test durations without omitting tests.

scripts/playwright-pr-shards.mjs

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can tweak Display settings with a live preview to see your comment before it ships

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

Qodo Fixer

No findings are available for this PR yet. Findings appear here once Qodo has reviewed the PR.

[codeant-ai]

CodeAnt PR Risk: Medium Risk

• The PR needs attention before merging because the tablet shard balance is not fully validated.
• Many tablet durations are extrapolated from mobile-WebKit after the tablet run stopped early; confirm real tablet shard times meet the 13-minute target.

Assessed commit: e970c1161b71