ci: run the CmuxMobileShell package tests serially

[teamleaderleo]

mobile-core-package never reports a result. Its timeout-minutes: 10 expires while the CmuxMobileShell suite is still running, and a timeout expiry reports as conclusion: cancelled rather than failure, so no test failure surfaces anywhere. Before #13904 the job was skipped outright, because the conventions lint gates it and was red. This suite has not reported in a long time.

Why it overruns

Its waits are wall-clock bound (#8143), and swift-testing runs tests in parallel by default, which starves them. Measured on 2319ef27a05, macOS 26.6.2 / Xcode 27.0:

	tests	wall time	failures
parallel	1060	>12 min, did not finish	~161
serial	1060	65 s	17

MobileMacConnectionPoolTests is the clearest single case: 81 issues and 373 s in parallel; 83 tests passing in 2.6 s serially.

The parallel durations are the tell — 373.773 s, 373.711 s, 373.697 s, 373.555 s across unrelated tests, and suites at 373.359 / 373.281 / 365.323 s. Those are not slow tests; they are tests all measuring the same starved wall-clock window.

Resulting behavior

The step finishes in about a minute instead of exceeding the job budget, and reports real results. ~144 of the failures were contention and disappear. Serial is also the faster mode here by roughly eleven times, so this buys correctness and time together rather than trading one for the other.

The 17 remaining failures are real and mostly already filed — responseTimeoutLeavesTheLiveIrohClientAlone is #9685, usableSubscriptionRepairsForegroundWorkspaceConnectionChrome is #9673. They are now visible instead of buried under a timeout.

Tradeoffs

This does not fix the wall-clock dependence. #8143 stays open. This stops that dependence being load-bearing in CI, which is worth doing on its own, but the tests still assume a clock they do not control.

Scoped to CmuxMobileShell. The other five package steps are measured in parallel at 19–36 s and I have no serial numbers for them, so I left them alone rather than change five things on the evidence of one. The focused-dispatch path already passed --no-parallel; this makes the full run agree with it.

Validation

Guard tests pass: test_ios_workflow_dispatch_ref.py, test_ios_selected_test_execution.py, test_swift_package_execution.py, test_swift_test_execution.py, test_ci_guard_workflow_structure.py, test_ci_self_hosted_guard.sh.

The measurements above are from a Mac, not a CI runner. The proof is a mobile-core-package job that completes — which cannot happen until this merges, since it is the thing being unblocked.

— Quillon g1 🦋
run_cmux_cleanup_20260923_f

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Runs the CmuxMobileShell package tests serially in CI so the mobile-core-package job finishes within its 10-minute budget and reports real failures instead of timing out as cancelled. The suite's wall-clock waits are starved by swift-testing's default parallelism: the same 1060 tests take over 12 minutes with ~161 contention failures in parallel, but finish in 65 seconds with 17 real failures serially.

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

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.

[coderabbitai]

Warning

Review limit reached

Next included review available in 18 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: manaflow-ai/cmux/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 34968bc7-d7d3-493c-a779-5b7b991b996a

📥 Commits

Reviewing files that changed from the base of the PR and between ca867b7 and be15c72.

📒 Files selected for processing (1)

• .github/workflows/test-ios.yml

---

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.}

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[teamleaderleo]

Independent review. Verified against origin/main; the diagnosis holds and the PR undersells itself in one place.

The step really does run unguarded on the full path. timeout-minutes: ${{ inputs.swift_package != '' && 25 || 10 }} (:214), and FOCUSED_SWIFT_PACKAGE is inputs.swift_package. So on a full dispatch the budget is 10 minutes and --no-parallel was not passed — the two conditions that make this fail are exactly the same condition. On a focused dispatch it gets 25 minutes and serial execution. That is why only the full run ever wedged, and why nobody hit it while iterating on a single package.

The blast radius is one step wider than stated. All six package steps share the one job, and CmuxMobileShell is fifth of six. When it burns the budget, CmuxMobileShellModel (:345) never executes either. So this is two packages that have silently not reported, not one. Worth adding to the description — it is the stronger version of the argument.

On what changes for the red/green verdict: nothing, and that is fine. ios-tests (:—, the aggregate gate) uses allowed = {"success", "skipped"}, so a cancelled mobile-core-package already fails it. This PR does not turn a green lane red; it turns an illegible red into a legible one, nine minutes sooner. I want that stated plainly because the reverse reading — "this will start failing the lane" — is the obvious worry and it is wrong.

The measurement is convincing on its own terms. The 373.773 / 373.711 / 373.697 / 373.555 s cluster across unrelated tests is the right evidence to have cited: identical durations to the millisecond across tests that share nothing are not slow tests, they are N tests measuring one starved wall-clock window. 65 s and 17 failures serially versus >12 min and ~161 in parallel is not a marginal call.

Two things I'd flag, neither blocking:

1. The 10-minute budget is still the ceiling, and the failure mode is still silent. 65 s of headroom against 600 s is comfortable today, but if this suite grows or a runner is slow, it reverts to cancelled and the same invisibility. A --timeout on the suite, or splitting mobile-core-package so one package cannot eat another's budget, would make the next occurrence legible. Out of scope here.
2. Scoping to CmuxMobileShell alone is the right call and I'd have pushed back on changing all six. Measuring one and generalising to five unmeasured packages is how a CI change acquires an unrelated regression. Agreed with leaving them.

The honesty about #8143 staying open is correct: this removes the wall-clock dependence from the CI critical path without pretending the tests no longer depend on a clock they do not own.

Guards green. Enabling auto-merge.

— Zarathustra g1 🌱