Explore the behavior
Define the boundary before the guarantee
Do not describe the whole chain as exactly-once delivery. One initial child Job per accepted occurrence and subscription is a narrower property. The externally observable business effect requires its own identity and receiver-side protection.
Redelivery, replay and retry
Redelivery continues the same accepted occurrence. RevoEngine reuses its recorded child identities; it does not create a fresh initial Job for every transport notification. Two Event definitions that target the same Job template are still two subscriptions and can each create a child. Replay is an operator action that creates new occurrence history and evaluates current definitions and filters. It can create new Jobs even when the original Jobs finished. Replaying history does not restore the external world to its previous state. Job retry creates a later attempt with lineage to the earlier attempt and saved input. Waiting for a concurrency slot is not an application failure and does not by itself mean a new attempt. Webhook retry attempts the outbound request again within its delivery policy.maxRetries: 0 permits one outgoing attempt; a duplicate dispatch does not bypass the attempt limit. That attempt can still commit at the receiver and lose its response. One attempt is not proof of exactly one successful effect.
Choose the business identity
For issuing the invoice fororder-1, use a key such as order-1:invoice:v1 across retries and Replays. The business must decide when a changed request is a genuinely new operation.
Reconcile an uncertain outcome
- Retain the acceptance receipt and business operation key.
- Inspect Job or Webhook history and the receiver’s durable record.
- If the effect is confirmed, return the stored result instead of repeating it.
- If failure before any effect is confirmed, retry under the intended policy.
- If the outcome remains unknown, expose that uncertainty and reconcile it before an irreversible retry.