[josephschorr]

Motivation

A large stack of PRs was marked ready for review at once, starting a burst of reviewbot sessions at the same moment. The cluster could not schedule all of their sandboxes ("Insufficient cpu / memory"), so the ones that didn't fit waited. Every one still waiting at the 8-minute sandbox readiness deadline then failed together, even though the earlier sessions were about to finish and free exactly the room they needed.

Separately, when a session ended this way, or any other way the agent itself didn't close out (a failure before it started, a crashed agent), its Slack thread kept showing it as still working: the status line stayed up, and plan cards kept their in-progress hourglass.

Summary of changes

Hold sessions for capacity instead of failing them

• A session whose sandbox is waiting because the cluster is full is now held, not failed at the readiness deadline. It starts on its own once the scheduler finds room.
• The session carries a new CapacityHold condition while held. Its thread gets a "Queued for cluster capacity" notice that says when the hold will give up. For triggered sessions this notice is also what opens the thread, so a queued review is visible instead of silent.
• The hold lasts up to one hour by default. It can be changed or turned off with a new operator flag, --capacity-hold-timeout. When a hold expires, the failure message says the cluster never had room, rather than blaming the session's tools.
• Only capacity shortfalls are held. A sandbox that can never fit, or one blocked for another reason (a taint, a storage placement conflict), still fails at the usual deadline with the specific cause.
• Once a held sandbox is scheduled, the usual startup deadline restarts from that point, so a session isn't failed while its image is still pulling.
• The silence watchdog treats a held session as an expected wait, so it no longer posts "taking longer than expected" or a stalled verdict over the queued notice.

Clear "working" indicators when a session ends

• When a session reaches a terminal state, its channel status line is cleared. On Slack, any plan card still showing an in-progress step is re-rendered as stopped. Cards that already finished, or that the agent already closed out, are left alone.
• When the watchdog gives up on a stalled session, it now also takes down its "taking longer" status line.

Alternatives considered

• Raising the readiness deadline for everyone. Rejected because genuinely broken sandboxes (a crashing container, a bad image) would also take an hour to report.
• A separate queue that admits sessions as capacity frees up. Rejected because a pending pod already is a queue: the scheduler places it the moment room appears. Holding means not giving up on it, with no extra resume step to get wrong.

Provenance

• Author: Joseph Schorr
• Person who read the diff: Joseph Schorr

Ship gate

• mage test:unit
• mage test:integration
• mage test:e2e

All three suites pass on the final tree. An earlier unit run had one websocket timeout in an unrelated web package; it passes on its own and passed in the full re-run. The machine was heavily loaded at the time.

Regeneration

• No CRD-shaping fields or RBAC markers changed: the new state is a status condition. n/a
• No config/** changes. n/a
• No cobra command or CRD schema changes. n/a
• Go code is gofmt-clean. mage fmt:check couldn't run locally because of a package-manager signature error in the markdown/TypeScript formatter step.

Coverage

• This adds user-visible behavior, and no bronzethread bundle covers it yet. Unit tests cover the hold (held, expired, disabled, non-capacity stall, mid-session regression, release), the queued and failure notices, the terminal cleanup, and the plan-card finalizer.
• Does not touch authorization, the SpiceDB schema, or the approver model.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
openagentprimitives	Ignored	Preview	Nov 6, 2026 4:38pm UTC