Handle Retries and Recovery
Recover from interrupted commands without sending duplicate transactions.
Keep the Submission ID
When submitting from a script, save the successful JSON result in durable job storage. Keep the original request with it. Human output also prints a status command while the submission is pending.
A successful command can return a queued operation, not a confirmed transfer.
Retry Reads, Not Transfers
namera --output json execution status 0199dfe1-0000-7000-8000-000000000003{
"namespace": "eip155",
"submissionId": "0199dfe1-0000-7000-8000-000000000003",
"status": "submitted",
"userOperationHash": "0x1111111111111111111111111111111111111111111111111111111111111111"
}This is safe to repeat for the same submission. If authorization fails, restore the connection before checking again. If rate-limited, follow the error's recovery instruction before retrying.
By contrast, a new execution execute command creates a new operation. Do not
wrap it in a generic shell retry loop.
A lost response is not a failed transfer
The transaction may already be queued or submitted. Check the existing submission before allowing another execution.
Understand Internal Retries
Within a single execution, the SDK retries transient preparation and completion requests up to three times each. It reuses the operation's idempotency key or submission ID. It does not automatically retry policy denials or other declared business failures.
There is no CLI flag to reuse an execution idempotency key across process restarts. A lost response is not proof that nothing was submitted.
Recover a Lost Result
If you know the submission ID, continue checking it. If you do not, mark the job unresolved and inspect the dashboard and confirmed execution history before allowing another attempt:
namera execution listAn empty history does not rule out a pending operation. Compare the account, network, recipient, amount, and timing; matching values alone cannot uniquely identify repeated legitimate transfers.
Fix a known rejection before intentionally submitting a replacement. Do not automatically repeat an uncertain signing command either, since another attempt can consume another signature allowance.
Example output uses fixture accounts and hashes, captured with the CLI's output formatters. Plain-text output is shown without terminal colors; your values and relative expiry dates will differ.