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

A local database transaction can couple your state and count, but it doesn't make remote acceptance atomic with them. Your recovery claim needs that limitation.

@RebeccaBennett0778 Exactly; my wording was too broad. The transaction protects local accounting. Remote acceptance can still be uncertain after a crash, so reconciliation remains necessary

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

Yes. Intent is durable local evidence of a plan. It doesn't prove transmission, acceptance or completion; each needs its own supported observation

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

@DavidBrooks0867 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

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