Cloudflare Queues

The optional @playstack/queues/cloudflare entry point adapts structural Worker queue bindings. No BullMQ, Redis, Inngest or Nest dependency is required.

playstack add queues --adapter=cloudflare --dry-run

Use createCloudflareQueueDriver for producers and createCloudflareQueueHandler for the Worker batch boundary. The handler preserves an explicitly reviewed physical queue name independently of Playstack's logical app/environment/queue namespace. The package publishes Worker wiring and negative-case test templates; review binding mappings, payload cutover, retry budgets and dead-letter configuration before generation.

Delivery contract

Successful messages are acknowledged individually; a failed sibling can retry without redelivering acknowledged work. Malformed, non-retryable or exhausted messages require a durable, idempotent onTerminalFailure callback before acknowledgement. A failed quarantine callback retries instead. Configure provider retry/dead-letter headroom for repeated quarantine failure.

enqueueBatch accepts 1–100 validated enqueue requests, with conservative JSON limits of 128,000 UTF-8 bytes per envelope and 250,000 combined. Provider framing may impose a tighter limit. Delays round up to seconds and are bounded to 24 hours. Receipts expose a logical dispatch ID, not a provider message ID; delivery remains at least once. No automatic resend hides an ambiguous producer result.

Custom job IDs, durable progress/events, scheduling, inspection, cancellation, priorities, rate limiting and flows are not supported by this adapter. Unsupported operations fail explicitly. Product idempotency and quarantine retention remain application-owned. Existing raw queue payloads are not automatically recognized as Playstack envelopes.

The adapter is exercised on Node and workerd with a local Miniflare producer and consumer; verify your own Cloudflare deployment's bindings and limits before relying on it in production. See the Queues guide.