View Issue Details

IDProjectCategoryView StatusLast Update
0006550Talerwallet (TS core)public2020-10-03 14:10
ReporterFlorian Dold Assigned ToFlorian Dold  
PrioritynormalSeveritytweakReproducibilityhave not tried
Status resolvedResolutionno change required 
Target Version0.8Fixed in Version0.8 
Summary0006550: API design: decide whether retries for synchronous operations should be driven by wallet-core or UI/client
DescriptionFor 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.
TagsNo tags attached.


Florian Dold

2020-09-01 15:41

manager   ~0016801

grote, grothoff and me should agree on this!


2020-09-01 15:50

developer   ~0016803

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.

Christian Grothoff

2020-09-05 01:42

manager   ~0016866

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.

Florian Dold

2020-09-08 18:05

manager   ~0016931

Current API is fine. Discussed on Mumble: Actions where the end user expects a synchronous result should return immediately and not retry.

Issue History

Date Modified Username Field Change
2020-09-01 15:40 Florian Dold New Issue
2020-09-01 15:40 Florian Dold Status new => assigned
2020-09-01 15:40 Florian Dold Assigned To => Florian Dold
2020-09-01 15:41 Florian Dold Assigned To Florian Dold => Christian Grothoff
2020-09-01 15:41 Florian Dold Status assigned => feedback
2020-09-01 15:41 Florian Dold Note Added: 0016801
2020-09-01 15:50 grote Note Added: 0016803
2020-09-05 01:42 Christian Grothoff Note Added: 0016866
2020-09-05 01:42 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2020-09-05 01:43 Christian Grothoff Status feedback => assigned
2020-09-05 13:53 Christian Grothoff Severity minor => tweak
2020-09-08 18:05 Florian Dold Status assigned => resolved
2020-09-08 18:05 Florian Dold Resolution open => no change required
2020-09-08 18:05 Florian Dold Note Added: 0016931
2020-10-03 14:08 Christian Grothoff Fixed in Version => 0.8
2020-10-03 14:10 Christian Grothoff Target Version => 0.8