MULTI-REGION A2A · TASK FAILOVER
Multi-region A2A: resume a task after home-region failure
Commit a ten-step A2A task in a home region, replicate it to a standby, fail the home region and resume: count lost steps and duplicate side effects.
Your experiment
Task t-17 has ten steps and sends an email at steps 4 and 8. The home region commits a step every three seconds and fails at 14 s. Watch which committed steps the standby has when it takes over, then change the lag, the replication mode and the idempotency switch.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Timing model of task ownership and replication, not an A2A server. Each step takes 3 s; synchronous replication adds 1 s per step for the cross-region write; the standby takes over after the detection delay and runs the remaining steps at 3 s each. Step effects happen when the step commits. Region names, task and email are fictional.
Ownership moves, history may not
Task t-17 has ten steps owned by a home region. Each step commits every three seconds, and steps 4 and 8 send an email when they commit. Asynchronous replication copies each commit to a standby region after a lag; when the home region fails, the standby detects it after a delay and resumes the task from the last step it has. Any step the home region committed but had not yet replicated runs again.
The opening failure: one lost step, one duplicate email
With a 4 s lag and a failure at 14 s, the home region has committed steps 1 to 4 at 3, 6, 9 and 12 s, but the standby has only steps 1 to 3; the copy of step 4 would have arrived at 16 s. The standby takes over at 17 s and runs step 4 again, sending the customer a second email, then finishes step 10 at 38 s. Check Email provider deduplicates by task/step idempotency key and the repeat is suppressed: the step still reruns, but the effect happens once.
Lag sets how much history is lost
Set Asynchronous replication lag to 0 and nothing is lost: the standby resumes from step 5 and finishes at 35 s with no duplicate. Set it to 10 and only step 1 has arrived, so steps 2 to 4 run again, the task finishes at 44 s and step 4 sends its email twice. Move Home region fails at to 26 s with the opening lag: step 8 is the lost step, and its email is the one duplicated. At 40 s all ten steps finish at 30 s and no failover is needed.
Synchronous replication and detection
Set Replication to the standby region to Synchronous: every commit waits for the standby, so steps take 4 s, only steps 1 to 3 are committed by 14 s, all of them are already in the standby, and nothing is redone. The cost is slower progress before the failure. Failure detection delay only shifts the takeover: at 10 s the task finishes at 45 s instead of 38 s. The lag control has no effect in synchronous mode.
Inspecting the run and its limits
Play, Next event, Restart, Speed and Inspection time step through commits, the failure, the takeover and every resumed step across sixty seconds; the chart shows home progress, the standby copy and resumed progress against modeled seconds, and the table lists every step. The model has one task, a perfect failure detector and no split brain, client retries, push notifications or A2A protocol messages; the idempotency key is an application design, not an A2A field.