Skip to content

fix(sync): don't shut down the wallet when a transaction data request fails#598

Open
s1ckoleg wants to merge 2 commits into
zcash:mainfrom
s1ckoleg:fix-nonfatal-tx-data-requests
Open

fix(sync): don't shut down the wallet when a transaction data request fails#598
s1ckoleg wants to merge 2 commits into
zcash:mainfrom
s1ckoleg:fix-nonfatal-tx-data-requests

Conversation

@s1ckoleg

@s1ckoleg s1ckoleg commented Jul 13, 2026

Copy link
Copy Markdown

Fixes #599.

When servicing a GetStatus/Enhancement transaction data request fails with a backend error — e.g. the transaction was reorged away and the validator answers RPC -5: No such mempool or main chain transaction — the data-requests sync task exits and takes the whole wallet process down. The request is regenerated from the wallet database on every startup, so one stale request crash-loops the wallet until systemd gives up (start-limit-hit).

This change logs the failure and leaves the request for a later sync iteration instead, matching how TransactionsInvolvingAddress servicing errors are already handled. Once the chain index catches up with the reorg, the request resolves through the existing None → TxidNotRecognized path. Wallet database errors still abort as before.

Tested with cargo check -p zallet-core and cargo fmt; the failure mode was reproduced live on testnet (v0.1.0-beta.1, zebrad 6.0.0) — details in the linked issue.

🤖 Generated with Claude Code

Servicing errors for GetStatus/Enhancement transaction data requests
previously aborted the data-requests sync task, which exits the whole
wallet process. A transaction that is reorged away between being
requested and being fetched surfaces as a backend error (the zaino
backend returns the validator's RPC -5 "No such mempool or main chain
transaction" as a ChainIndexError), and because the request is
regenerated from the wallet database on every startup, one stale
request put the wallet into a permanent crash-loop that ended in
systemd start-limit-hit.

Log the failure and leave the request for a later sync iteration
instead, matching the existing handling of TransactionsInvolvingAddress
servicing errors. Wallet database errors still abort as before.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@s1ckoleg
s1ckoleg force-pushed the fix-nonfatal-tx-data-requests branch from 2b07efa to ec35e42 Compare July 13, 2026 22:40
Comment thread zallet-core/src/components/sync.rs
Comment thread zallet-core/src/components/sync.rs
…equests

Per review: invalid data from the chain source is not retryable (it
indicates a bug, corruption, or a version mismatch), so it still aborts;
Unavailable and Backend errors are logged and retried.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@pacu
pacu requested a review from nullcopy July 16, 2026 21:34

@pacu pacu left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wallet crash-loops permanently when a data-requested transaction is reorged out

2 participants