Two regions resume the same agent step. How do you stop a duplicate write?

The hard question is what Region B knows when it takes over. If the checkpoint is asynchronously replicated, B may not know that A prepared an operation, sent it, or received a result. A lease in B cannot tell A's in-flight network request to stop. Waiting for A's lease to expire helps with new work in our own system. It does not unsend a write to a payment or ticket provider.

I would put the run's ownership and operation ledger under one authoritative ordering path, backed by a quorum or another store that can reject stale epochs. Each logical external action gets a stable ID based on the business action, run, and step semantics. Before either worker sends it, it records the exact target and arguments as prepared under the current epoch. A worker whose epoch is old cannot advance the run or prepare a new effect. Region B must acquire the next epoch from that authority and read the operation ledger before deciding what it can do.

That implies an availability choice. During a partition where neither region can reach the authoritative path, I would pause new external writes for this workflow rather than let both regions independently decide they own it. Read-only analysis might continue in a clearly speculative branch, but it cannot commit a tool effect. If the system promises active-active writes despite losing that authority, it needs a different, explicitly reconciled business contract. Calling the system “multi-region” does not remove the single-decision requirement for one refund.

Even with a perfect epoch in our database, A might have sent a request milliseconds before losing its lease. The external provider does not check our epoch. B sees a prepared or attempted operation and treats the outcome as unknown until it checks the provider. If the provider supports a durable idempotency key, both regions use the same one with the same parameters within its documented scope and retention. If it supports lookup by our operation reference, reconcile first. A confirmed effect lets B record success and continue without another call.

Now take away provider fencing, as the question does. That alone is manageable if provider deduplication or a reliable lookup exists. Take those away too, and we cannot prove whether an unacknowledged request committed. Automatic replay could create a duplicate. The correct state is unknown and the run pauses for manual resolution or an application-specific audit path. A timeout cannot be promoted to failure because the old region is inconvenient.

The interviewer then points out that B's checkpoint predates the operation record. If the ledger itself is only on A and is asynchronously copied, B may generate the same logical ID but still not know a call was attempted. It must query the provider before sending, and if the provider cannot answer reliably, stop. Better is to make the operation ledger part of the authoritative pre-send commit. If that path is unavailable, the old system cannot safely offer automatic failover for writes. We should state that limitation before an incident, not discover it after two refunds.

I would rehearse this with a provider simulator. Pause A before send, after send, after provider commit, and before local success. Partition A from the state store, promote B from an intentionally stale snapshot, then let A wake again. Verify that only the current epoch writes local state, every retry carries the same operation ID and arguments, and no second external write occurs when the first result is unknown. Measure time stuck in unknown and the manual resolution backlog, not merely “workflow resumed.”

Google's Chubby paper is a primary example of an advisory distributed lock service. Temporal's Activity guidance notes why retryable activities need idempotent effects. The cross-region operation protocol here is the proposed design, not a guarantee supplied by either system.