Oracle Integration Cloud: Building Integrations That Survive Production · Module 9 · Idempotency and duplicate prevention
Timeouts: the ambiguous outcome
Lesson 98 of 175 · 2 min
A call that timed out MAY HAVE SUCCEEDED. Designing for "I do not know" rather than assuming failure — because the assumption is what creates duplicates. A timeout is not a failure response. It is the ABSENCE of a response. The target may have rejected the request, may have completed it, or may still be working on it. Those three are indistinguishable from where you are standing, and no amount of error handling changes that. THE NAIVE ASSUMPTION IS THAT IT FAILED, because a timeout looks like an error. Retry on that assumption and you create a duplicate every time the assumption was wrong — and it is wrong most often on a slow target, which is precisely when timeouts happen. DESIGNING FOR "I DO NOT KNOW" MEANS THREE THINGS. RECORD THE ATTEMPT BEFORE MAKING IT, so the ambiguity is visible afterwards — the staging row from Lesson 5. ON…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Integration Cloud: Building Integrations That Survive Production, with a certificate on completion and a fourteen-day refund window.
In this module: Module 9 · Idempotency and duplicate prevention
- 1Why every integration is retriedFree preview
- 2What idempotency means here
- 3Choosing a correlation key
- 4Where to enforce it
- 5When the target has no natural key
- 6Timeouts: the ambiguous outcome
- 7Idempotency across a whole file
- 8What breaks: three duplicate scenarios
- 9Lab briefing · Make a payment flow safe to retry