cloud: share concurrent VM stats reads

[teamleaderleo]

Problem

The Machines panel, surface registry, and CLI can ask for the same VM's resource stats at the same time. VMResourceStatsStore already fences ordering and resize/reset generations, but every caller still starts its own /api/vm/:id/stats request.

Change

Share only the active stats request for a given machine. This is single-flight, not a TTL cache: once the request settles, the next read fetches fresh data. Resize, reset, and retention invalidation fence the old task so a late completion cannot clear or overwrite a newer read. One consumer's cancellation does not cancel the shared request for other consumers.

Validation

• Added behavioral coverage for sharing, independent machines, failures/retry, retention/reset/resize invalidation, and stale completions.
• swiftc -parse passes for every changed Swift file.
• Full Xcode tests were not runnable in the fresh worktree because the vendor/bonsplit submodule is uninitialized; run the focused VMResourceStatsStoreTests target in CI or an initialized checkout.

Follow-up measurement

Use the Cloud startup/fleet harness with 1/10/50 machines and multiple panels to compare stats request count and foreground latency before and after. This PR removes duplicate in-flight work but does not claim an end-to-end latency number.

---

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

---

Summary by cubic

Shares concurrent reads of the same destination VM's resource stats so the Machines panel, surface registry, and CLI no longer each start their own /api/vm/:id/stats request.

This is single-flight, not a cache: once the active request settles, the next read fetches fresh data. Resize, reset, and retention invalidation discard the in-flight task so a late completion can't clear or overwrite a newer read, and one consumer's cancellation doesn't cancel the shared request for other consumers.

Testing

• Adds coverage for request sharing, independent machines, failures and retries, invalidation, and stale completions.
• swiftc -parse passes for changed files; the full Xcode suite needs the vendor/bonsplit submodule, so run the VMResourceStatsStoreTests target in CI.

^{Written for commit 2a32159. 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 12 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: feeb2c03-aea0-43c6-be55-b69211947679

📥 Commits

Reviewing files that changed from the base of the PR and between 02972b7 and 2a32159.

📒 Files selected for processing (4)

• Sources/Cloud/VMClient+ResourceStats.swift
• Sources/Cloud/VMResourceStatsStore+Entry.swift
• Sources/Cloud/VMResourceStatsStore.swift
• cmuxTests/VMResourceStatsStoreTests.swift

---

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

[greptile-apps]

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking cancellation-lifecycle issue that can retain cancelled stats consumers until the shared request settles.

Findings

1.  Cancellation Cannot Stop Waiting ▶

Summary

This PR adds per-machine single-flight sharing for active VM resource-stat requests while retaining fresh reads after each request settles.

• Stores the active request in the main-actor resource-state entry.
• Uses revision changes and entry removal to fence resize, reset, retention, and eviction invalidations.
• Adds behavioral coverage for request sharing, retries, independent machines, and stale completions.
• Cancellation no longer propagates to the shared fetch, but individual cancelled waiters also remain suspended until that fetch settles.

Diagram

sequenceDiagram
    participant C1 as Consumer 1
    participant C2 as Consumer 2
    participant Store as VMResourceStatsStore
    participant API as VM stats API
    C1->>Store: read(machineID)
    Store->>API: start shared request
    C2->>Store: read(machineID)
    Store-->>C2: existing Task handle
    C1-xC1: consumer cancelled
    Note over C1,API: Cancelled waiter remains suspended
    API-->>Store: response or timeout
    Store-->>C1: task settles, then cancellation is observed
    Store-->>C2: shared result
    Store->>Store: clear active task

Loading

_{Reviews (1) · Last reviewed commit: "cloud: share concurrent VM stats reads"}

[teamleaderleo]

Addressed the cancellation finding in stacked follow-up teamleaderleo#95. Each consumer now stops awaiting the shared stats fetch when canceled, while the underlying single-flight request remains available to other consumers; a regression test covers this separation.

[teamleaderleo]

Parked — Thornquay 💠 (triage, 2026-09-23). Merges cleanly into main, 4 files, and nothing has superseded the single-flight. The 8 failing checks are all macos / app-host unit tests (N/6) from 2026-09-21 — that is the pre-#13759 breakage on main, not this PR. To confirm that, it needs a rebase and a full Mac run, which is why it is parked rather than landed: the macOS pool is saturated and this is a contention optimization, not a bug fix. Good candidate once runners free up — the rebase should be a no-op.

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