Did my browser submission succeed before the automation crashed?

Why can a failed run still create a record?

Suppose row INV-1042 fills an invoice form and clicks Submit. The server accepts it, then the connection closes before the browser displays the receipt. The local process sees an interruption; the business system may already contain the invoice. Repeating the click could create a second record.

The recovery question is therefore whether the intended effect exists, not whether the automation returned successfully. The same uncertainty applies to an HTTP write or an MCP tool that times out: the remote action can finish after the client stops waiting.

What should I check before retrying?

1. Read the run report and identify the review row, its business key and destination account.
2. Look up that key at the destination. Compare the fields that define this operation: for an invoice, its reference, customer, amount and period.
3. If the effect exists, record its receipt or record ID and resolve the item as done.
4. If you have established that the effect did not occur, resolve it as failed. The next resume can submit it again.
5. If the evidence is inconclusive, leave it in review. An empty search result during delayed processing is not necessarily proof of absence.

Manual resolution requires an evidence note and explicit confirmation that someone checked the destination. It is recorded as a manual, unverified decision. An agent must ask the user to confirm that check before setting confirmChecked. See the recovery reference for the exact commands.

How does Ritoko resume the rest of the batch?

Resume the existing run, using run_resume for a direct run or host_next for a host run. Confirmed rows remain confirmed. Failures before submission can be retried; uncertain writes stay held. The run uses its saved workflow and input snapshot, so editing the spreadsheet does not rewrite the interrupted batch.

A later run with the same workflow, scope and key also respects that review hold. If another run is blocked by the original uncertain item, resolve the original run first. Do not use a new workflow name, scope or journal as a shortcut around uncertainty.

What makes the next interruption easier to resolve?

Mark the one irreversible operation with commit: true, then check a result specific to that row with expect. A generic Success banner is weak evidence; a matching reference or receipt is more useful. Treat an autosaving field or upload that creates a record as a write too.

Ritoko tracks actions through this installation. It cannot see independent submissions, make a remote site idempotent or infer the correct outcome from missing evidence. Split a task with several irreversible effects into separate procedures whose outcomes can each be verified.