View Issue Details

IDProjectCategoryView StatusLast Update
0007568Talerwallet (WebExtension)public2023-09-23 15:09
Reportersebasjm Assigned Tosebasjm  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.9.3Fixed in Version0.9.3 
Summary0007568: implement the new semantic of aborting/cancel/forgetting/resuming a tx
Descriptioncheck the extendedStatus field
TagsNo tags attached.

Relationships

related to 0006590 closedFlorian Dold clarify UX for (partially) failed payments 

Activities

sebasjm

2023-02-14 15:33

developer   ~0019835

https://git.taler.net/docs.git/tree/design-documents/037-wallet-transactions-lifecycle.rst

If aborted is an end state, resuming a aborted tx should create a new one.
WDYT?

Florian Dold

2023-02-16 22:24

manager   ~0019853

I don't think "aborted" should be an end state. Having multiple versions of basically the same transaction would be very confusing.

sebasjm

2023-02-17 13:53

developer   ~0019864

Well, my argument for using aborted transaction as and end state is because running again the transaction may be done based on different conditions and the old aborted tx have important information that should not be lost.

Maybe we should put some examples

 * On withdraw, the transaction may be aborted from the bank or from the wallet. This information need to be saved. If the withdrawal was initiated from the bank, resuming won't be possible because I understand resuming the withdrawal as creating a new manual withdraw.
 * Aborted transfer or invoices can't reuse purse, so it will need to pay that fee again. Am I correct?
* Aborted payment, when restarted again, will have different contract. Old payment tx will have the amount spend (fees) and refund associated.

Florian Dold

2023-02-17 14:51

manager   ~0019865

I think the details in DD37 should clarify this.

All your examples would be non-resumable aborted transactions, so effectively we *are* creating new transactions in these cases. It just has nothing to do with the resume mechanism. So we practically agree here?

The only place where resuming aborted transactions makes sense if the abort wasn't destructive. For example, aborting a withdrawal where the money was already wired.

sebasjm

2023-04-10 16:44

developer   ~0020054

Closing this since DD37 is in progress

Issue History

Date Modified Username Field Change
2023-01-12 16:28 sebasjm New Issue
2023-01-12 16:28 sebasjm Status new => assigned
2023-01-12 16:28 sebasjm Assigned To => Florian Dold
2023-01-12 16:28 sebasjm Assigned To Florian Dold => sebasjm
2023-01-12 16:30 sebasjm Relationship added related to 0006590
2023-02-10 16:05 Florian Dold Summary implement the new semantic of aborting/cancel/forgetting a tx => implement the new semantic of aborting/cancel/forgetting/resuming a tx
2023-02-14 15:33 sebasjm Note Added: 0019835
2023-02-14 15:33 sebasjm Assigned To sebasjm => Florian Dold
2023-02-14 15:33 sebasjm Status assigned => feedback
2023-02-16 22:24 Florian Dold Note Added: 0019853
2023-02-17 02:54 Florian Dold Assigned To Florian Dold => sebasjm
2023-02-17 02:54 Florian Dold Status feedback => assigned
2023-02-17 13:53 sebasjm Note Added: 0019864
2023-02-17 13:53 sebasjm Assigned To sebasjm => Florian Dold
2023-02-17 13:53 sebasjm Status assigned => feedback
2023-02-17 14:51 Florian Dold Note Added: 0019865
2023-02-17 14:52 Florian Dold Assigned To Florian Dold => sebasjm
2023-04-04 15:54 Florian Dold Target Version git (master) => 0.9.3
2023-04-10 16:44 sebasjm Note Added: 0020054
2023-04-10 16:44 sebasjm Status feedback => resolved
2023-04-10 16:44 sebasjm Resolution open => fixed
2023-04-13 20:37 Florian Dold Category wallet (WebExtensions) => wallet (WebExtension)
2023-09-23 15:07 Christian Grothoff Fixed in Version => 0.9.3
2023-09-23 15:09 Christian Grothoff Status resolved => closed