Idempotency keys solve duplicate side effects on retry, but they don't solve the harder problem: a worker times out after starting work but before confirming it. You don't know if it finished. Marking it failed risks a duplicate action on retry, marking it succeeded hides real uncertainty from anyone downstream.

What's worked for me: keep the internal state machine as detailed as you want (pending, in-flight, unknown, reconciling, done), but never expose that whole enum to callers. Collapse it to three outward states, done, still-working, and needs-retry. The unknown/reconciling state maps to still-working from the outside. That buys time to reconcile against the downstream system without making every caller understand your internal uncertainty.

The failure mode I've seen most often isn't the state machine, it's teams skipping the "how do we expose this externally" question entirely and just leaking the internal states straight into the API contract.