Superseded-Work Cancellation

When three commits land on a branch while the first build is still queued, only the last one usually matters. When a webhook is delivered twice, both deliveries produce the same build. When a user retries a request that was already accepted, the queue now holds two copies of identical work.

Cancelling superseded work converts a queue of duplicates into a queue of distinct jobs, and during a burst that is frequently a larger saving than any capacity addition.

Why it matters

It is one of the few controls that is simultaneously cheap to build, large in effect, and free of trade-offs for the common case. Most capacity interventions cost either money or user experience; this one costs neither.

It also improves latency for everyone, because the queue is shorter, which is the property that matters when a developer is waiting for a build.

Implementation patterns

• Define supersession explicitly per work type. For a branch build it is "a later commit on the same branch". For a report generation it is "a later request for the same parameters". For a sync it is "a later change to the same entity". The definition is domain knowledge and it cannot be inferred generically.
• Deduplicate identical in-flight work by a content key, so concurrent identical submissions collapse to one and both callers receive the same result.
• Cancel only queued work by default, not running work, unless the running job is long and clearly wasted — cancelling in-flight work has a cost and a partial-effect risk.
• Tell the user. A silently cancelled build looks like a lost build. The status must say superseded, with a link to the run that replaced it.
• Never supersede work with side effects that have already been depended on — a deployment that something else is waiting for, a payment, a notification already promised.

Industry example

Deployment platforms such as Vercel, Railway and Render face this on every popular framework release, when thousands of projects rebuild within a short window and many of them push several times. Device-testing platforms such as BrowserStack face the same shape when a CI pipeline retries a suite.

The economics are stark: with a heavy-tailed submission pattern, a meaningful fraction of queued work is already irrelevant when it starts.

Failure scenarios

• Superseding work that had a side effect somebody was waiting on, which turns a saving into a broken workflow.
• Silent cancellation, indistinguishable from a lost job.
• Deduplication by an unstable key, so identical work is not recognised as identical.
• Cancelling running work indiscriminately, wasting the compute already spent and leaving partial state.
• No supersession at all, so a burst is served at several times its necessary cost.

Trade-offs

Supersession assumes the later submission fully replaces the earlier, which is true for idempotent, whole-state work and false for incremental work. A build of commit C does not tell you whether commit B passed, which matters if the team needs per-commit status for bisecting.

The usual resolution is configurable per project: supersede by default, with an option to build every commit for teams that need the history. That puts the trade where it belongs — with the team that knows whether per-commit results are worth the queue time.

Interview question

"During a burst your build queue is forty minutes deep. Before you add capacity, what would you look for in the queue itself, and what could you safely remove?"