View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006550 | Taler | wallet-core | public | 2020-09-01 13:40 | 2021-08-24 14:23 |
| Reporter | Florian Dold | Assigned To | Florian Dold | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | tweak | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Target Version | 0.8 | Fixed in Version | 0.8 | ||
| Summary | 0006550: API design: decide whether retries for synchronous operations should be driven by wallet-core or UI/client | ||||
| Description | For tasks that are just *started* via wallet-core and happen in the background, wallet-core handles all the retry logic. For synchronous operations, we still need to agree on how to handle retries. Examples for such operations are: * adding a new exchange * claiming contract terms * sending a payment (or proof of re-payment) to the merchant Let's take the example of adding a new exchange via URL (possibly obtained via scanning a QR code). What happens if the *first* request to /keys returns 5xx? There are three options: (a) The wallet-core never retries requests for the operations. The UI either has to show the user a message (with the option to re-try) or initiate the retry itself. (b) The wallet-core makes a fixed/limited number of retries (via timeout?) and then returns a success or error response Option (a) could be more convenient for the UI. However, option (b) nudges UIs to display better messages for transient errors. | ||||
| Tags | No tags attached. | ||||
| grote, grothoff and me should agree on this! | |
| For adding a new exchange I'd use option (a) if done by the user. Don't know what claiming contract terms is about. As for sending a payment (or proof of re-payment) to the merchant, it probably depends on what kind of error we are getting. Fatal errors should be shown to the user right away so they know the payment has failed. If there are unlikely transient errors, we can retry, but it isn't ideal because the user doesn't know what happened to the payment and if they need to pay again or not and if so when. | |
| I think for all of these operations it would probably be best to give the user quick feedback: the user is online and interacting with the wallet. Waiting for X retries with many seconds of delays between retries (that are all likely to have the same result!) doesn't make sense. | |
| Current API is fine. Discussed on Mumble: Actions where the end user expects a synchronous result should return immediately and not retry. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-09-01 13:40 | Florian Dold | New Issue | |
| 2020-09-01 13:40 | Florian Dold | Status | new => assigned |
| 2020-09-01 13:40 | Florian Dold | Assigned To | => Florian Dold |
| 2020-09-01 13:41 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2020-09-01 13:41 | Florian Dold | Status | assigned => feedback |
| 2020-09-01 13:41 | Florian Dold | Note Added: 0016801 | |
| 2020-09-01 13:50 | grote | Note Added: 0016803 | |
| 2020-09-04 23:42 | Christian Grothoff | Note Added: 0016866 | |
| 2020-09-04 23:42 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2020-09-04 23:43 | Christian Grothoff | Status | feedback => assigned |
| 2020-09-05 11:53 | Christian Grothoff | Severity | minor => tweak |
| 2020-09-08 16:05 | Florian Dold | Status | assigned => informing |
| 2020-09-08 16:05 | Florian Dold | Resolution | open => no change required |
| 2020-09-08 16:05 | Florian Dold | Note Added: 0016931 | |
| 2020-10-03 12:08 | Christian Grothoff | Fixed in Version | => 0.8 |
| 2020-10-03 12:10 | Christian Grothoff | Target Version | => 0.8 |
| 2021-08-24 14:23 | Christian Grothoff | Status | informing => closed |
| 2023-04-13 18:36 | Florian Dold | Category | wallet (TS core) => wallet-core |