Summary
After PR #278, transaction types other than Stake (e.g. Unstake) that land late or aren't found within the verification window are now silently marked Failure. Previously they surfaced as a loud, retriable error and stayed Pending for triage. There is no positive-evidence fallback for non-stake transactions.
Detail
PR #278 added a Tier-4 supplier-state fallback that only applies to Stake transactions: extractStakeAddresses only matches /pocket.supplier.MsgStakeSupplier, so for an Unstake it returns {} and the fallback in ExecuteTransaction.ts is skipped (if (operatorAddress && ownerAddress)), leaving success = false → TransactionStatus.Failure is persisted.
Before this PR, when no operator address could be extracted (always the case for non-stake txs), the old verifyTransaction threw Transaction data is incomplete or not found. That error propagated uncaught, so the workflow failed and the transaction stayed Pending/retriable — visible for triage, never silently marked Failure.
Impact
An unstake (or any non-stake tx) that actually landed on-chain but whose hash isn't found within the ~30-block window — due to tx_index lag or an RPC hiccup, i.e. the exact scenario PR #278 exists to handle for stakes — is now permanently mislabeled Failure, with no recovery path. Downstream node/DB state can diverge from on-chain reality.
Fix
Provide a positive-evidence fallback for non-stake transaction types (or, at minimum, do not write a terminal Failure when verification was inconclusive for a type that has no fallback — keep it retriable/triageable as before). Generalizing the recovery to "did the intended on-chain state change happen?" per tx type is the deeper fix than the stake-only special case.
Summary
After PR #278, transaction types other than
Stake(e.g.Unstake) that land late or aren't found within the verification window are now silently markedFailure. Previously they surfaced as a loud, retriable error and stayedPendingfor triage. There is no positive-evidence fallback for non-stake transactions.Detail
PR #278 added a Tier-4 supplier-state fallback that only applies to
Staketransactions:extractStakeAddressesonly matches/pocket.supplier.MsgStakeSupplier, so for anUnstakeit returns{}and the fallback inExecuteTransaction.tsis skipped (if (operatorAddress && ownerAddress)), leavingsuccess = false→TransactionStatus.Failureis persisted.Before this PR, when no operator address could be extracted (always the case for non-stake txs), the old
verifyTransactionthrewTransaction data is incomplete or not found. That error propagated uncaught, so the workflow failed and the transaction stayedPending/retriable — visible for triage, never silently markedFailure.Impact
An unstake (or any non-stake tx) that actually landed on-chain but whose hash isn't found within the ~30-block window — due to
tx_indexlag or an RPC hiccup, i.e. the exact scenario PR #278 exists to handle for stakes — is now permanently mislabeledFailure, with no recovery path. Downstream node/DB state can diverge from on-chain reality.Fix
Provide a positive-evidence fallback for non-stake transaction types (or, at minimum, do not write a terminal
Failurewhen verification was inconclusive for a type that has no fallback — keep it retriable/triageable as before). Generalizing the recovery to "did the intended on-chain state change happen?" per tx type is the deeper fix than the stake-only special case.