Trigger.dev pause concurrency limit vs Sume queue_full 429

Pausing a Trigger.dev concurrency limit holds runs in Trigger.dev's queue, so a paused run has not called Sume yet and there is nothing in Sume to cancel for it. If Sume itself returns 429 queue_full, that is a separate limit: your Sume workspace has no room for another paid generation job. Back off using retry-after.

Trigger.dev v4.7.0 (2026-10-01) adds concurrencyLimits.pause(name), which stops every run holding the limit from being dequeued while keeping its configured bounds, and concurrencyLimits.resume(name). Sume side: Generation admission and Errors and credits, read 2026-10-01.

What does pause do to runs that already called Sume?

The release notes describe only dequeuing, so they do not say what happens to a run that is already executing. A Sume job submitted by such a run keeps its own lifecycle: poll GET /v1/jobs/:id/status or cancel it with POST /v1/jobs/:id/cancel (cancel succeeds only before generation starts). Do not resubmit a paid request just because a local process stopped.

How does a named limit line up with Sume's concurrency?

Sume generation concurrency is plan-only: prepaid top-ups do not raise it. Jobs beyond it are accepted as queued while queue capacity remains, and the default capacity is max(3, concurrency_limit × 5). A Trigger.dev named limit set at or below your plan's processing concurrency keeps most submits out of Sume's queue.

import { concurrencyLimit, concurrencyLimits } from "@trigger.dev/sdk";

// A limit any task can hold; match your Sume plan's processing concurrency.
export const sumeLimit = concurrencyLimit({ name: "sume", total: 4 });

// Call these from an operator script or API route, not at module scope.
export async function holdSume() {
  // Hold queued runs back without changing the bounds.
  await concurrencyLimits.pause("sume");
}
export async function releaseSume() {
  await concurrencyLimits.resume("sume");
}

What does queue_full mean, and what do I do?

queue_full means workspace generation concurrency plus queue capacity is full. It is different from rate_limited: the docs say Sume cannot accept another paid generation job until a queued or processing job finishes or is canceled. Concurrency being full by itself is not an error. On 429, use retry-after when present, and do not retry unsafe submits without an Idempotency-Key.

Should a paused limit and queue_full share one retry policy?

Keep them separate. Pause is an operator decision in Trigger.dev; queue_full is a signal to wait. A retry rule that skips other 4xx codes but waits on 429 matches Sume's docs, as covered in Trigger.dev retry: skip 4xx, honor Sume 429 retry-after.