View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012154 | Taler | wallet-core | public | 2026-11-15 19:38 | 2026-11-15 19:38 |
| Reporter | bot-cg [agent] | ||||
| Priority | normal | Severity | minor | ||
| Status | new | ||||
| Summary | 0012154: wallet-core: transaction states that offer neither delete, abort nor fail -- a transaction parked there can never be removed by the user | ||||
| Description | The UIs offer for a transaction exactly what txActions lists. Read from the computeXxxTransactionActions functions (taler-typescript-core master 150044e2b), these states list none of Delete, Abort, Fail: withdrawal PendingReady Retry, Suspend SuspendedReady Resume PendingQueryingStatus (funded) Retry, Suspend SuspendedQueryingStatus (funded) Resume PendingKyc (funded) Suspend, Retry SuspendedKyc (funded) Resume PendingRedenominate / Suspended~ Retry, Suspend / Resume FinalizingKycHardLimit Retry deposit SuspendedDeposit Resume Aborting (one branch) Retry peer-pull-credit PendingWithdrawing / Suspended~ Retry, Suspend / Resume ExpiredDeletePurse / Suspended~ Retry, Suspend / Resume FinalizingKycHardLimit Retry peer-pull-debit AbortingReconcile / Suspended~ Suspend / Resume peer-push-credit AbortingMerge Retry FinalizingKycHardLimit Retry refresh Pending, PendingRedenominate Retry, Suspend Suspended, SuspendedRedenominate Resume recoup Pending / Suspended Retry, Suspend / Resume Most of these are meant to be brief. They stop being brief when the other side never answers: the payment service is gone or unreachable for good (refresh, recoup, withdrawal PendingReady, the delete-purse and reconcile states), or the user declines the legitimization (the funded KYC states). Then the transaction stays, and the user has no action that ends it. Deleting the whole payment service is the only way out, and that removes everything else that belongs to it as well. Seen in practice with the iOS wallet's UI fuzz harness: a funded withdrawal in pending(kyc), offering Suspend only, in 10 recorded episodes. The rule this is measured against (maintainer, 2026-11-15): no state may be impossible to delete; it may be hard. So the question for each row is what the hard way out is -- for a funded withdrawal presumably "abandon: give up the withdrawal, the reserve is closed and the money is wired back by the payment service after its usual delay"; for a refresh or recoup against a dead service "fail: accept the loss of these coins". Fail (or a new "abandon") in these states would give the UIs something to show. Not checked by me: whether any of these states is unreachable in practice, and what the Android and web wallets show for them. | ||||
| Tags | No tags attached. | ||||
| child of | 0012147 | new | iOS wallet: state the user can never delete -- audit against the rule that every item must be individually removable [meta] |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-11-15 19:38 | bot-cg | New Issue | |
| 2026-11-15 19:38 | bot-cg | Relationship added | child of 0012147 |
| 2026-11-15 19:38 | bot-cg | Implementer | => avalos |
| 2026-11-15 19:38 | bot-cg | Reviewer | => oec |
| 2026-11-15 19:38 | bot-cg | Release signed by | => Florian Dold |
| 2026-11-15 19:38 | bot-cg | Deployed by | => oec |
| 2026-11-15 19:38 | bot-cg | Verifier | => oec |
| 2026-11-15 19:38 | bot-cg | Communicator | => CM_7 |