Four ordinary events, each producing a second delivery of the same work. None of them is a defect, which is why every integration is retried eventually.
ONE: A TIMEOUT THAT SUCCEEDED. The caller gave up; the target completed. Neither system is wrong and they disagree, and whatever happens next is a coin flip: retry and duplicate, or give up and lose the work.
TWO: A RESTART. A run died halfway and somebody ran it again. Whatever the first run committed is committed twice unless something prevents it.
THREE: A RESUBMISSION. An operator reprocessed a failed instance from the console — which re-runs the flow from the beginning, including the steps that succeeded. Module 8's lesson, arriving as a duplicate.
FOUR: A PARTNER WHO RESENDS. They had an outage, they were not sure the first file arrived, somebody clicked twice. You have no control over this one at all, which is what makes it the clearest argument: the defence has to be in your design because it cannot be in theirs.
ALL FOUR ARE ORDINARY OPERATIONS RATHER THAN FAILURES, and that is the point of this lesson. An integration that is only safe when everything works is not safe, because these four happen in the ordinary course of a year.
So the design question is not "will this be retried" but "what happens when it is" — and that question has to be answered for every write an integration makes, at design time, because it cannot be retrofitted after the duplicates exist.