> ## Documentation Index
> Fetch the complete documentation index at: https://docs.accelmars.com/llms.txt
> Use this file to discover all available pages before exploring further.

# When a confirmation is lost

> A database may have committed even when the caller never receives its acknowledgement.

Gateway asks the database to commit an attempt record. The connection fails before the confirmation arrives.

Did the commit fail? It may have. But it may also have succeeded, with only the acknowledgement lost. **A missing reply is not proof of rollback.**

This illustrative case explains why Gateway keeps the original operation identity and resolves that operation rather than replacing it with a new one.

## Preserve the question that needs answering

Before the write, the original owner must retain the operation, call and attempt identities, expected record content and the authority context needed to interpret them.

After a lost reply, the question is “did this exact operation commit in the authoritative history?” It is not “can I find any row with a similar identifier?”

A matching identifier on the wrong database, an old restored copy or a lagging replica is not sufficient evidence. The applicable native-capacity and execution records must also agree.

## Use a qualified confirmation path

```mermaid theme={null}
%%{init: {"flowchart": {"nodeSpacing": 20, "rankSpacing": 30, "padding": 12}}}%%
flowchart TB
    A["Commit reply is lost"] --> B["Keep the original identity<br/>and expected evidence"]
    B --> C["Check authoritative history<br/>with a qualified reader"]
    C --> D["Matching confirmation,<br/>conflict, or unresolved"]
    D --> E["Advance only when the<br/>original contract permits"]
```

The reader needs current, narrowly scoped permission and the correct history or restore generation. This is not permission for ordinary serving code to inspect every private witness table.

A matching confirmation resolves the database question. It does not automatically prove that the provider received a request or permit a resend of work that may already have been dispatched.

## Why an absent row is not enough

The original transaction may still be able to commit. Or the reader may be seeing a stale copy. In either case, “not found” cannot safely mean “nothing happened.”

Negative confirmation is meaningful only when the original transaction can no longer commit and the reader is observing the authoritative acknowledged history under the required controls.

Adding a timeout does not create that proof. The runtime still needs bounded observation and a responsible owner for unresolved work.

## The next action depends on the boundary

For an attempt registration that the original live owner has not yet dispatched, matching confirmation may permit the already-authorized send, provided all current checks still hold.

For an output marker, missing confirmation means meaningful content cannot be released. Possible exposure must not be dismissed simply to allow a replacement answer.

For a final record, the complete final and notification graph must be confirmed before the applicable success can be returned. The application still owns its answer storage, and financial owners still resolve any separate money effect.

## Four uncertainties, not one

Database commit, provider execution, recipient delivery and financial settlement each have their own evidence. Resolving one does not resolve the other three.

Local experiments covered pending commits and lost confirmations for specified protected boundaries. They did not prove every protected wait is bounded or establish universal exactly-once behavior at remote providers.

Read [Investigating a request](/public/gateway/operations/monitoring) for the operational questions and [Recovery after a storage failure](/public/gateway/operations/restore) for restored history.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.