View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008441 | Taler | wallet-core | public | 2024-02-19 14:38 | 2026-09-19 14:44 |
| 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 | feature | Reproducibility | have not tried |
| Status | informing | Resolution | fixed | ||
| Target Version | 1.6 | Fixed in Version | 1.6 | ||
| Summary | 0008441: wallet-core should long-poll withdrawal operation *and* reserve at the same time | ||||
| Description | ... instead of waiting for the withdrawal operation before even contacting the exchange. | ||||
| Tags | performance | ||||
| IMO this threatens to completely break the nice, uniform state machine, error handling and retry approach we have for wallet-core transactions. What happens if one of the long poll endpoints returns an error status (immediately)? Do we now have two separate "error" properties on the transaction now? How do we handle retry counters in this case? Do we have two separate ones? A possible approach: * Ignore all errors from the exchange long-polling while we are in pending(bank-confirm-transfer), don't report them outside of logs, we won't be able to show them in the UI * Run an additional background task that is coupled to the normal withdrawal task and has its own retry counter and long-polling logic (i.e. preventing a "short" long-poll and doing back-off when the long-poll endpoint returns 5xx). All this seems like an awful lot of complexity for something that's only needed when the bank services goes offline but the exchange still works. | |
| While the normal long-polling is trivial, this "double long-polling" seems excessive especially for 0.9.4. | |
| I'd probably say ignore (transient) exchange errors until/unless you have an answer from the bank (but not if say /config or /keys indicate this isn't even an exchange!), and otherwise if bank long polling ends with failed, cancel exchange. If bank long polling ends with 'success', keep exchange long polling until success there, too. Then do /withdraw. If exchange gives you a really hard error (5xx, or /{keys,config} tell you not-an-exchange), possibly *abort* the bank transfer (if you still can) as this is not an exchange and thus /withdraw would fail later (and that'd be worse!). Anyway, 0.9.5 is fine ;-), as would post-1.0, I guess. | |
| commit f50000ab21a6cfbab86b797e19afc376c77e7ae3 (HEAD -> master, origin/master, origin/HEAD) Author: Florian Dold <dold@taler.net> Date: Sat Aug 22 17:59:06 2026 +0200 wallet-core: poll bank and reserve concurrently Issue: https://bugs.taler.net/n/8441 | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-02-19 14:38 | Florian Dold | New Issue | |
| 2024-02-19 14:38 | Florian Dold | Status | new => assigned |
| 2024-02-19 14:38 | Florian Dold | Assigned To | => Florian Dold |
| 2024-02-19 14:38 | Florian Dold | Target Version | => 0.9.4 |
| 2024-02-20 00:56 | Florian Dold | Note Added: 0021382 | |
| 2024-02-20 00:57 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2024-02-20 00:57 | Florian Dold | Note Edited: 0021382 | |
| 2024-02-20 00:58 | Florian Dold | Note Added: 0021383 | |
| 2024-02-20 00:58 | Florian Dold | Note Edited: 0021383 | |
| 2024-02-21 20:39 | Christian Grothoff | Note Added: 0021429 | |
| 2024-02-21 20:39 | Christian Grothoff | Severity | minor => feature |
| 2024-02-21 20:39 | Christian Grothoff | Note Edited: 0021429 | |
| 2024-02-21 21:33 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-02-22 12:51 | Florian Dold | Target Version | 0.9.4 => post-1.0 |
| 2025-04-17 22:08 | Christian Grothoff | Assigned To | Florian Dold => |
| 2025-04-17 22:08 | Christian Grothoff | Status | assigned => implementing |
| 2025-04-17 22:08 | Christian Grothoff | Tag Attached: performance | |
| 2026-08-22 16:01 | Florian Dold | Assigned To | => Florian Dold |
| 2026-08-22 16:01 | Florian Dold | Status | implementing => informing |
| 2026-08-22 16:01 | Florian Dold | Resolution | open => fixed |
| 2026-08-22 16:01 | Florian Dold | Note Added: 0029544 | |
| 2026-09-19 14:40 | Christian Grothoff | Fixed in Version | => 1.6 |
| 2026-09-19 14:44 | Christian Grothoff | Target Version | post-1.0 => 1.6 |