A workflow timeout tells me that an attempt did not finish cleanly from the caller's perspective. It does not tell me whether the business effect happened.
That uncertainty is central to retry design. Repeating an operation can recover missing work, duplicate completed work or apply an old instruction after the source has changed.
My public ecommerce operating-layer case describes normalized demand, explicit exceptions and workflows designed to recover without creating duplicate work. This note develops the identity questions behind that pattern. It proposes a review contract rather than documenting a new production schema or a measured delivery guarantee.
Separate three things that can look like one event
The source event describes something reported by an authoritative system. The processing attempt describes a particular effort to handle it. The business effect describes the work the application intends to create or change.
Those identities should not collapse into the same value merely because one trigger started the workflow.
An attempt identifier helps explain which execution failed. It does not necessarily identify the intended effect. Conversely, an effect identity can remain stable across attempts, while the attempt history records different outcomes.
The exact keys depend on the domain and source guarantees. I would first ask which source object or revision defines the intent, what makes two effects equivalent, and where the system can authoritatively check completion.
An invented interruption
Imagine a fictional order event that should create a production-review item. The worker submits the item, but loses the response before it can record success.
Starting another worker with a new attempt identifier is appropriate for diagnostics. Creating another production item simply because the attempt is new would duplicate the intended work.
A proposed retry contract would preserve the original effect identity and consult the authoritative completion state before deciding what to do. If the source order had since changed, that revision would need an explicit relationship to the original intent. It should not be disguised as another attempt at an unchanged operation.
This is a design illustration, not a real order or a claim that one identifier can guarantee exactly-once execution across arbitrary systems.
The check belongs near the effect
A workflow-level flag can be useful, but it can also become stale. If two attempts both read “not completed” before either writes success, the flag alone does not prevent duplicate effects.
For a concrete implementation, I would inspect the actual effect boundary: what operation can reject an equivalent duplicate, what record establishes completion and how competing attempts are resolved. The answer might involve a transactional constraint or a destination-provided idempotency contract. This note does not prescribe either as an already deployed feature.
The recovery path also needs to preserve uncertainty. “Request sent” and “effect confirmed” are different outcomes. If the destination cannot confirm either success or absence, the item may require reconciliation rather than another blind send.
For reports, the same distinction applies to calculation and delivery. Recomputing a narrative can be harmless while sending it again is a separate external effect.
A retry review checklist
- Can the source intent be identified independently of the worker attempt?
- Is an updated source revision distinguishable from a replay?
- Is the intended business effect defined precisely enough to detect an equivalent duplicate?
- Where is completion checked, and can competing attempts race past that check?
- Does the record distinguish attempted, uncertain and confirmed effects?
- Can unresolved cases be reconciled without pretending that a timeout means failure?
- Are report generation and report delivery tracked as separate operations?
These questions help make a recovery design inspectable. They do not prove the behavior of a live connector. That requires tests against its actual guarantees, interruption scenarios and observed reconciliation outcomes.
The public ecommerce operating-layer case provides the operational context for this identity boundary.
Which identity in your workflow survives a retry, and which identity should change with every attempt?
Top comments (0)