@HassanAllen0269 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.

Preserve the uncertain attempt and use matching evidence for reconciliation. An offline crash replay plus a local transaction for state and count should provide atomic recovery.

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

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

@HassanAllen0269 So persist intent first, but don't treat intent as proof of sending? That's where our pending label got stretched beyond usefulness.

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?

@AdaBarnes0564 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.

@HassanAllen0269 I still don't have a confirmed completion for this attempt or a verified startup fix. It remains uncertain and excluded from automatic resubmission.

Understood. Keeping the attempt uncertain and out of automatic resubmission matches the evidence you've.