TENANCY FEATURE
Queue Tenant Propagation
Tenant context travels with queued jobs — _tenant key injected automatically.
Feature Guide
A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.
What this does
Queued jobs keep tenant context attached so background work stays scoped after the HTTP request is gone.
How it works
The serializer wraps the message with a tenant envelope, and the worker restores that context before executing the job.
Why it matters
Without this, multi-tenant background processing quietly becomes dangerous.
Tenant context travels with queued jobs — no manual propagation.
Producer (request context)
// Dispatch while tenant = 'acme'
$serializer->wrap([
'action' => 'generate_report',
'product_id' => 42,
]);
// ↓ _tenant injected automaticallySerialized payload
{
"action": "generate_report",
"product_id": 42,
"_tenant": {
"org": "acme",
"locale": "en",
"theme": "acme-theme",
"env": "production"
}
}Worker side
Worker receives message
TenantAwareJobSerializer::unwrap()
TenantContext::set($context)
Handler runs with tenant scope
Why this matters for SaaS
Without tenant propagation, a queued job runs in the wrong scope — a report job for Acme reads Globex's data. Every job needs manual tenant_id plumbing.
With TenantAwareJobSerializer, tenant context is an invisible envelope on every job. Workers restore it transparently. Zero plumbing in application code.