Make Email Automation Replayable with Run IDs

Description and use

Email automation often feels random because the job has no durable identity. A CI workflow sends a message, waits for a link, and reports a timeout, but it does not leave a clear answer to which exact run owned that message.

Problem

Email-driven automation often feels random because the job has no durable identity. A CI workflow sends a message, waits for a link, and reports a timeout, but it does not leave a clear answer to the basic question: which exact run owned that message.

Outcome

The run ID pattern gives email automation a durable correlation key connecting the trigger, temporary inbox, observed messages, extracted link, and final result. Failed jobs become inspectable and replayable instead of simply re-run and hoping to succeed.

Workflow

• Create the run ID before the first side effect
• Allocate an inbox or alias for that run
• Start the application action with the run ID as correlation data
• Poll only for messages that belong to the run
• Save the evidence and result under the same ID

Evidence

Email-driven automation often feels random for one simple reason: the job has no durable identity.

A run ID gives the workflow a small, useful memory. It connects the trigger, the temporary inbox, the observed messages, the extracted link, and the final result.

Suppose a test creates an account and waits for verification email. The inbox may already contain an older message. A retry may create a second account. A parallel CI job may use the same mailbox.

The important fields are run_id, inbox, the trigger time, and the message identifier.

Do not call a replay idempotent just because it has a run ID. The receiving operation still needs an idempotency key, a duplicate check, or a deliberate compensation step.

Is a run ID useful outside testing? Yes. Deployment notifications, password-reset checks, and scheduled data jobs all benefit from a durable correlation key.