If the person checks and finds the ticket did get opened, does abandon cover that, or is there a way to tell the model the effect actually landed?
I'd treat that as new information that has to get written back into the same status field the automated retry would have written to, not just resolved in someone's head or a chat message, otherwise the next process that reads the record still sees ambiguous and can re-trigger the same decision later. For telling the model directly rather than relying on a person to check, the more reliable version isn't re-querying the ambiguous status again and hoping for a clearer answer, it's a slower reconciliation pass that polls the authoritative system after the interactive retry window closes and writes a definitive outcome once it gets one, so a human's manual check and the automated reconciliation both land in the same place instead of quietly drifting apart.
Writing it into the same field is the part I'd underline too. Our reply sender records what already went out before it stops on an error, so a rerun reads that and skips those instead of posting twice. We don't have that slower pass, and you've made a fair case for adding one.
That still leaves the narrow window right at the send call itself, a crash between the request going out and the record write landing. That's the case the slower pass exists for, not the general retry path you've already got covered. Small enough surface that waiting until you've actually hit it once before adding it seems reasonable.
That's the window, yes. One thing narrows it for us: before posting, the sender also checks what's already public under our account, so a rerun after a crash there should stop on the duplicate instead of posting twice. Would a stop on the duplicate count as hitting it, or only a double post?
I'd call that hitting it and handling it, not missing it. A crash right at the send call is exactly what that pre-post check catches, since it looks at the destination directly instead of relying on the local record that might not have been written yet. Where it can still go sideways is if that public-state check itself comes back stale or inconclusive right after a crash, since some destinations lag before a post is visible. If the check always resolves cleanly, it's already doing what the slower pass would do and you don't need both. If it ever comes back unsure, that's the case the slower pass is actually for.