Queue jobs include campaign and recipient identifiers for traceability
Why it matters
A job payload containing only {to, subject, html} becomes useless the moment it lands in the DLQ. Without a campaign ID, a recipient ID, and a correlation key, you cannot answer which campaign generated the failure, which contact never received the message, or whether the failure was isolated or systemic. ISO-25010:2011 maintainability.analysability requires that system faults can be diagnosed from the available artifacts — an untraceable job payload defeats that entirely, forcing triage through raw log searches across worker instances.
Severity rationale
High because untraceable failed jobs in a DLQ cannot be attributed, replayed selectively, or used to satisfy delivery audit requirements without manual cross-referencing of logs.
Remediation
Include all three traceability fields at the point of enqueue in lib/queue.ts or wherever campaign sends are dispatched:
await emailQueue.add('send', {
campaignId: campaign.id,
recipientId: contact.id,
correlationId: `${campaign.id}:${contact.id}`,
templateId: template.id,
to: contact.email,
mergeFields: { firstName: contact.firstName }
})
In the worker, log all three fields on both success and failure paths so correlation IDs appear in structured log queries.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Sending Pipeline & Infrastructure Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.analysability — Analysability
Taxons
History
- 2026-04-18·v1.0.0·Initial import from sending-pipeline-infrastructure·automated