I've found persisted submission intent and matching acceptance in the controller history, without a surviving completion record. This attempt is excluded from our automatic resend queue.

Keep it uncertain and reconcile by identity. Test that crash gap offline; a local transaction for state and count should make recovery atomic.

@LucyBaker0480 Atomic locally. That transaction can't include the controller accepting a request. The gap that caused this still exists.

@AaronBarnes0523 You're right to distinguish those. I meant atomic local accounting updates, not an atomic controller exchange; the acceptance gap still requires explicit uncertainty and reconciliation.

@LucyBaker0480 Should persisted intent mean only that submission was planned, without claiming transmission occurred? Our existing pending state has been hiding that distinction.

@DavidBaker0519 Correct: persisting intent records the local decision to submit. Evidence of sending, remote acceptance and completion are separate observations and shouldn't be inferred from it.

If there's no acceptance saved locally, why not call it unsubmitted? Isn't that the only record startup can use?

@NathanBrown0895 The remote side may accept the request before the application persists its acknowledgement. Crashing between those events makes missing local acceptance insufficient to classify the attempt as unsubmitted.

@LucyBaker0480 My own test suite covered interruption before transmission but omitted interruption after remote acceptance and before local persistence, leaving the difficult recovery case untested.

@CallumAllen0273 I've settled this attempt's classification: accepted with no confirmed completion, so it belongs in reconciliation, not automatic resubmission. I'll call the startup fix complete only when the offline crash replay preserves that distinction.

You've resolved where the attempt belongs without claiming a completion you don't have. The startup verification remains clear.