Why Our Ten Parallel Clones Stopped Accepting New Tickets on July 18

On July 18, five of our ten clone cells looked unavailable even though the tickets tied to them were already finished or closed.

That stalled new work before anyone had written a line of code. We run ten parallel clones of the same repository so developers and agent sessions can take separate tickets without grinding on the same checkout. The unit I care about is the clone cell: a checkout, the ticket it is serving, and the branch that may still contain work. At that scale, an abandoned claim is a capacity leak.

A full pool, and two ways to empty it

The pool looked full. The fast fix was to wipe the status board, mark every clone free, and start dispatching again. That recovers apparent capacity immediately, but it treats every old claim as dead. One of the ten cells was carrying an in progress prototype branch, and another feature branch was local only, with nothing on the remote behind it. A blanket clear would have turned a scheduling problem into a recovery problem.

Trusting the existing occupancy marks is the opposite failure. The pool stays safe, and finished work becomes a permanent reservation. Neither approach separates a stale claim from work that merely stopped at a good breakpoint.

So we audited all ten cells against their tickets. The result split into three groups. Five cells were attached to work that was finished or closed. Three were on open tickets. One prototype branch was deliberately parked on its clone. After freeing the five stale or done occupancies, six cells were available for new work.

That count is the evidence the cleanup changed usable capacity. Three active cells, one parked prototype and six open cells account for the full pool of ten.

What the ticket can’t tell you

A closed ticket usually means the application work is complete. It says nothing about whether the checkout holds something that exists only there.

The local only feature branch showed this. Its ticket state made the cell look releasable. Its branch state meant that clearing it without a decision could discard the only copy of unfinished work. The follow up was explicit: push it to the remote if the work needed safeguarding, otherwise leave the audit closed. That is a better question than “is this clone old?”

The sequence we use now:

1. Start with the pool, not the session that happens to be noisy.
2. Match every clone cell to its current ticket state.
3. Separate finished or closed work from open work.
4. Check whether an apparently stale cell has a branch that still needs a home.
5. Free only the cells whose ticket and branch state agree.

This is deliberately narrower than a universal cleanup command. An automatic age threshold would be tempting, especially when an agent session dies without updating its claim. It would also be wrong for the parked prototype. Time is only a signal.

More clones, more state to go wrong

The early mental model was that more clones meant more parallelism. That is true but incomplete, because more clones also mean more state that can become inaccurate. A clone does not stop being occupied because an agent went quiet. It stops being occupied when we can show that its ticket, branch and intended next action no longer need that cell.

That is why we treat the pool audit as operating work. It took 4 hours and 59 minutes to audit all ten cells and free five of them. It is not glamorous, but it opened six cells for new work without destroying a prototype or losing a local branch.

Ten clones do not give us ten times the throughput by themselves. They give us ten places where a stale claim can hide, and the capacity comes back only when we clear those claims with evidence.

What to check before you free a cell

If you run parallel workspaces for people or agents, audit the pool against ticket state and branch state before freeing anything. A closed ticket does not show that a checkout holds no unique work, so look at whether each stale-looking cell has a branch that needs a home. Free only the cells where both agree.

dxdev LESSON · paste into your AI coding agent
LESSON: At scale, an abandoned resource claim is not an edge case, it is a capacity leak, and a ticket's status is the first diagnostic, not the whole one
SOURCE: dxdev.com/blog/locks-across-ten-clones
WHAT HAPPENED: Five of ten shared repository checkouts looked occupied even though the tickets tied to them were already finished or closed, which was enough to stall new work before anyone had written a line of code. A blanket reset marking every checkout free was rejected because one checkout carried an in-progress prototype branch and another held a local-only feature branch never pushed to the remote, either of which a blind clear would have destroyed. Trusting the existing occupancy marks unconditionally was equally wrong, since it would let finished work permanently reserve capacity. The audit instead checked both ticket state and branch state for all ten checkouts, splitting them into finished-or-closed, genuinely open, and deliberately parked, and only freed the checkouts where ticket and branch state actually agreed, with the local-only branch specifically flagged for a human decision, push it to safeguard the work or explicitly abandon it, rather than either auto-preserving or auto-discarding it.
THE RULE: A shared resource pool's ticket-tracking state and its actual underlying state, a branch, an uncommitted checkout, can disagree, and checking only one of them either destroys unfinished work or leaves a growing set of stale claims; capacity comes back only by checking both signals together and freeing exactly the resources where they agree, not through an automatic time-based threshold, which would wrongly destroy anything deliberately parked.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any shared resource pool, checkouts, worker slots, sessions, whose occupancy is inferred from only one signal, such as a ticket's status, without also checking the actual underlying state that could still need protecting.
      2. Any proposed cleanup of a stuck or stale-looking resource pool that is a blanket reset or a blanket trust, rather than an item-by-item audit against multiple independent signals.
      3. Any automatic age- or time-based cleanup threshold applied to a resource pool where a legitimately long-lived, deliberately parked claim could exist and get destroyed.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.