The duplicate appointment begins with a reasonable retry.
A caller asks for Tuesday at 3 p.m. The agent submits the booking request. The tool times out. The workflow sees an error and tries again. Both requests reach the scheduling system. The agent executed the same tool twice, and the customer now has two appointments.
The opposite failure is possible too. The first request succeeds, the response disappears, and the workflow refuses to retry. The agent apologizes for failing. The customer hangs up believing there is no appointment, then receives a confirmation for one.
Counting tool calls cannot settle either case. The question is whether the intended change exists exactly once in the business system.
Name the effect before the request
Engineers often discuss exactly-once execution as a property of messages, jobs, or handlers. The customer does not care how many times a handler ran. The customer cares whether one appointment exists for the agreed service, address, and time.
Those are different claims.
A request can execute once and produce no appointment. It can execute twice and still produce one appointment because the provider rejects duplicates. It can time out at the client after producing the appointment. The transport history and the business history overlap, but neither one determines the other.
I start by writing the effect that must be true outside the agent. For an appointment, it might be:
One active appointment exists for this customer, service, location, and authorized time, and the provider has returned an identifier that can be used to inspect or change it.
This statement does more work than “the booking call succeeded.” It defines the object, the uniqueness boundary, and the evidence needed later.
Give the attempt an identity
Every consequential action needs an identity that survives retries.
The identity should refer to the customer’s intended operation, not one network request. If a workflow creates a fresh identity after each timeout, the receiving system cannot distinguish a retry from a second booking.
The useful key depends on the business operation. A payment may use an authorization identifier. A message may use a campaign and recipient pair. An appointment may use an operation identifier tied to the caller’s confirmed choice. The key must remain stable until the first attempt is resolved.
This does not guarantee that every external system will enforce uniqueness. It does give the workflow a durable fact to search for, record, and pass to an operator.
Treat unknown as a state
Most retry bugs begin when a workflow forces an unknown result into success or failure.
A timeout proves that the response did not arrive in time. It does not prove that the appointment was rejected. Once the request may have crossed the boundary, the action is unresolved.
I use four states for the effect:
- Unattempted: no request has been sent.
- Attempted: the request was sent, but the external effect has not been established.
- Confirmed: the system can identify the intended external effect.
- Contradicted: the system can establish that the intended effect does not exist or cannot complete.
Attempted is the state that prevents the dangerous retry. The workflow may reconcile, wait, query by operation identity, or transfer ownership. It may not pretend that uncertainty is failure merely because failure is easier to route.
Reconcile before repeating
The first recovery action should gather evidence about the first attempt.
The best path is a provider lookup using the operation identity. If the provider cannot search by that identity, the workflow may query the customer record and match on the authorized fields. If the available API cannot distinguish the intended appointment from an older one, the system should say so and transfer the case with the attempted parameters intact.
The reconciliation result controls the next move:
| Observation | Safe next action |
|---|---|
| The intended appointment exists once | Confirm it and continue |
| No matching appointment exists, and the provider establishes rejection | Retry within the original authorization |
| More than one matching appointment exists | Stop automation and repair the duplicate |
| The provider cannot establish the state | Wait or transfer; do not create another appointment |
The table is deliberately strict. A retry is allowed only when new evidence rules out the first effect.
Put the claim at the business boundary
Queues, databases, and tool clients can reduce duplicate execution. They cannot define what counts as a duplicate business outcome.
That definition belongs at the boundary shared by product, operations, and engineering. Product defines the intended effect. Engineering records the attempt and obtains evidence. Operations owns cases the system cannot resolve. If any one of those pieces is missing, “exactly once” is only a local implementation claim.
Before releasing a consequential action, I ask:
- What external effect must exist?
- Which fields make that effect the same operation?
- Which identifier survives a timeout and retry?
- How can the workflow inspect the first attempt?
- What blocks a second attempt while the result is unknown?
- Who owns an unresolved or duplicated effect?
The system does not need to promise that a request ran exactly once. It needs to keep one customer instruction from becoming zero, two, or an answer nobody can verify.