An EMS CAD status poller retries after transient timeouts. A naive retry calls the 'create incident ticket' API again and duplicates tickets. What must a safe retrying function ensure?
Select an answer to reveal the explanation.
Short Explanation
You need retries that don't stamp out twin tickets when the first create actually landed. Check status or use an idempotent create so a timeout doesn't mean 'make another one.'
Full Explanation
An EMS CAD status poller that retries after transient timeouts must not create duplicate incident tickets when a create-incident API call may have succeeded before the timeout was observed. A safe retrying function must avoid duplicate ticket creation—for example by checking ticket status first, using client-generated idempotency keys, or calling an idempotent create pattern before posting again. Retries then become safe under at-least-once delivery semantics. The approach where each timeout always opens a brand-new ticket even when the prior create likely succeeded produces twin tickets, confuses responders, and pollutes CAD-related workflows. Disabling all timeouts so hung polls block the dispatcher console forever trades duplicate risk for availability failure; hung calls can freeze operational visibility. Timeouts remain necessary; they must pair with idempotent retry logic. Storing API keys inside the ticket subject line for faster retries exposes secrets in ticketing systems and does nothing to make creates idempotent. Exam caveat: distinguish read retries (usually safe) from create/update retries (need idempotency); document which CAD APIs are safe to replay and which require status checks or idempotency keys. Operational check: simulate a create that succeeds server-side while the client times out, confirm the retry path does not open a second ticket, verify keys are not logged in subjects, and review production for duplicate EMS tickets correlated with timeout spikes after deployment.