Has anyone else been burned by OIC's "Abort" button in production?

Learned this one the hard way and I'm curious if others have hit it too.

An engineer on a support team I worked with bulk-selected an entire Errors page in OIC and hit Abort — to "clean up the dashboard." Those messages were gone. Permanently. Aborted instances can't be recovered by any means, and the source system had already marked them as sent.

That's data loss created by a UI button, and OIC gives you no warning beyond a line in the docs saying don't discard a message you want to resubmit.

A few related OIC monitoring gotchas that seem to catch people repeatedly:

• Resubmit restarts the flow from the beginning, not the failure point. If your integration already inserted a row or called an API before it faulted, a blind resubmit does all of it again.
• Synchronous flows can't be resubmitted at all — the option doesn't even appear. Recovery has to come from the caller.
• Business identifiers can't be edited once the integration is active. Pick the wrong field and you need a deactivate/reactivate window to fix it.

Questions for the group:

1. Has anyone actually lost data to an accidental Abort? How did you recover (or did you)?
2. Do you design for idempotency up front, or only after the first duplicate-payment incident?
3. Anyone using a parking-lot table for payload correction and beyond-retention recovery — or do you just live within OIC's retention window?

Curious what patterns people have landed on.