One queue, many tenants
Diesel uses one control plane for durable work. Client instances create jobs with their trusted tenant identifier, and the standalone worker resolves that identifier through worker_tenants before dispatching the operation.
Tenant credentials do not live in queue messages. The queue carries routing and operation data; protected configuration remains in server-side storage and environment variables.
The life of a job
- 01
Enqueue
A trusted tenant route writes an operation with a stable job identity.
- 02
Become available
Immediate work is ready at once; recovery work can have a future availability time.
- 03
Claim
The worker reads a visible job and temporarily hides it from competing workers.
- 04
Dispatch
The tenant is resolved and the original operation is sent to its configured instance.
- 05
Acknowledge
Successful work is removed; failed work remains available according to retry policy.
Immediate work and the safety cron
New jobs can wake the worker immediately, keeping completion and refunds responsive. A scheduled worker call remains as a safety net for missed triggers and delayed jobs.
The safety cron can run less frequently because it is no longer the primary path. Delayed aborts still become available only after their recovery window; waking the worker early does not make a future job runnable.
Retries and idempotency
Queue delivery is treated as at least once. A worker may see the same message again after a timeout, restart, or visibility-window expiry. Every financial operation must therefore be safe to repeat.
Observability and failures
The worker records successful and failed operations with the tenant, operation, timestamps, and available response details. Failed tasks also generate a notification so operational issues do not depend on someone watching server logs.
The Shopify admin Events page provides the merchant-facing view. Operators can inspect the full event detail, distinguish failed work from completed work, and avoid presenting no-op abort races as released funds.