A bridge relayer restart should resume the execution attempt already in progress. The difficult interval begins when a transaction has been signed or broadcast but the worker has not yet recorded a conclusive result. Starting another payout from the task's unfinished status can create a second attempt before the first has been understood.
Passage Bridge's current local relayer persists the signed transaction before broadcast. Its recovery path uses that transaction's hash, nonce and signed bytes. This article follows the inspected implementation and existing local recovery-test definitions. It does not report a new rehearsal or a mainnet result.
Persist the signed attempt before sending it
The worker first checks source finality, approval finality and the message's execution state. It verifies the message against the configured deployment and inspects chain health, approval and role constraints. It simulates the destination call before allocating a transaction nonce.
The worker then signs the transaction and saves an attempt containing the message hash, signer, nonce, transaction hash and raw signed transaction. Only afterward does it broadcast. If the process stops between the database write and the network call, the next worker can find the exact transaction it was preparing to send.
This ordering also helps when the network call times out after the node receives the transaction. The database already has the transaction identity, so recovery can ask about that identity. Raw signed bytes are operationally sensitive because they can authorize the recorded action when broadcast. Restrict access to the recovery store accordingly without putting private keys in API or indexer processes.
Reserve the signer's unresolved nonce
Passage's local worker takes an account lock keyed by chain and signer. It searches for outstanding signed attempts across deployments before selecting new work. An unresolved attempt from an older deployment blocks fresh nonce allocation for that account and must be recovered by the matching deployment's worker.
This scope is deliberate. A database task ID belongs to one application workflow, while the account nonce belongs to the signer on that chain. Multiple deployments using the same signer can collide even when their task tables appear independent. The recovery worksheet asks reviewers to exercise that overlap explicitly.
| Evidence on restart | Current local recovery behavior | Operator concern |
|---|---|---|
| Canonical receipt found | Store inclusion evidence and await indexed finality | Distinguish inclusion from final completion |
| Original transaction still visible | Keep the attempt pending | Do not allocate another payout |
| No transaction found and nonce available | Recheck policy, then rebroadcast original bytes | Preserve original hash and nonce |
| Nonce consumed by unknown transaction | Mark attention required | Identify the consuming transaction |
| Recovery attempts exhausted | Stop automatic rebroadcast | Review evidence before staff recovery |
Reconcile the receipt with indexed facts
A receipt can establish execution status at a block. The worker compares its block hash with the block returned by the node. For a successful receipt, the attempt remains included until the message projection identifies the matching claimed transaction. For a reverted receipt, it waits for indexed finality before treating that revert as final.
The Ethereum JSON-RPC reference provides separate methods for transaction lookup, receipts and account transaction counts. These observations answer different questions. Recovery needs to combine them with the bridge's own indexed message state, especially when one RPC response is unavailable.
If there is no receipt and the transaction is absent, the local worker rechecks the payout policy before considering rebroadcast. A changed approval or a chain-review condition can stop recovery. An unknown consumed nonce moves the attempt to attention required. The implementation also limits automatic recovery attempts to three, with scheduled retries.
Rehearse the actual crash windows
The repository contains recovery-test definitions for a transient source-RPC outage, an unknown nonce consumer and a missing receipt while a transaction remains pending. Other cases cover retry exhaustion, an unfinalized revert and account locks across deployments. These are useful starting points for a new environment's review, without treating their presence as fresh passing results.
Add a controlled stop immediately after persistence and another after broadcast. For each restart, compare the original attempt ID, transaction hash and nonce with the recovered record. Follow the destination payout and consumed message identity through to final indexed state. A worker returning success is only one observation in that chain of evidence.
The worksheet separates the interruption point, expected behavior and collected evidence. Every case is marked Not run. Keep a failed rehearsal's unresolved attempt intact so the evidence is available for review, and record any staff decision to resume it.
Download the relayer restart recovery rehearsal matrix.
Passage Bridge is an operated liquidity bridge demonstrated on local Anvil chains. Independent message approval is part of its model. Production automatic broadcast remains disabled; production signers, liquidity, RPCs and external security review require separate planning.
