View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006009 | Taler | obsolete component | public | 2019-12-23 23:20 | 2020-03-31 16:04 |
| Reporter | Christian Grothoff | Assigned To | Florian Dold | ||
| Priority | urgent | Severity | block | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.6 | Fixed in Version | 0.6 | ||
| Summary | 0006009: bank's /admin/add/incoming is not idempotent | ||||
| Description | When a wire transfer fails (or seems to have failed), taler-exchange-aggregator will repeat it. In this case, the bank MUST NOT do the wire transfer a second time (idempotent: doing the same thing twice is a no-op!). However, right now, the Python bank simply does the wire transfer again, even if _everything_ (accounts, subject and amount) is identical. We could consider this an issue of the libtalerbank API, which doesn't first ask for a unique transaction number (2-phase commit). This _would_ be supportable by the wire plugin. Right now, our logic is simplistic and simply repeats the same HTTP request again. However, the exchange DOES guarantee that the subject is unique except for idempotent requests. This recently was a major issue, because the (Python) bank violated the protocol by returning the data format in a way that was, eh, unexpected by the aggregator / libtalerbank. As a result, the aggregator believed that the request failed, and retried -- repeatedly, until the exchange account was empty. Boo! Temporary fix: deploy a bank that never fails (har har). This is urgent, ideally to be fixed before 36c3. | ||||
| Tags | No tags attached. | ||||
|
|
Here it would be VERY useful to know which data (a JSON field supposedly? Which one?) was not liked by the aggregator! |
|
|
The timestamp field of the response for making a wire transfer was encoded in a way the aggregator did not like (see recent format change of date fields!). Anyway, that has been fixed. The high-level issue that remains is that the aggregator expects requests to be idempotent, while the pybank doesn't implement that. Discussing with Florian, we think a good way would be to add a high-entropy UUID/request ID into the API, and if that value is not unique, the bank MUST reject the transfer if it differs in any dimension, and MUST decide it is a repeated request to be ignored if all fields (sender, receiver, amount, subject AND requestID/UUID) match. That way, we can do it with one request/RTT, and avoid the pitfall of a user manually intentionally doing a transaction twice, where everything including the wire transfer subject matches. |
|
|
Has been implemented in the python bank (and fakebank) a while ago. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-12-23 23:20 | Christian Grothoff | New Issue | |
| 2019-12-23 23:20 | Christian Grothoff | Status | new => assigned |
| 2019-12-23 23:20 | Christian Grothoff | Assigned To | => Marcello Stanisci |
| 2019-12-24 13:29 | Marcello Stanisci | Note Added: 0015219 | |
| 2019-12-24 14:08 | Christian Grothoff | Note Added: 0015220 | |
| 2020-01-27 21:42 | Florian Dold | Assigned To | Marcello Stanisci => Florian Dold |
| 2020-01-27 21:42 | Florian Dold | Status | assigned => resolved |
| 2020-01-27 21:42 | Florian Dold | Resolution | open => fixed |
| 2020-01-27 21:42 | Florian Dold | Note Added: 0015300 | |
| 2020-01-28 00:12 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2020-03-31 16:04 | Christian Grothoff | Status | resolved => closed |
| 2022-08-23 20:26 | Christian Grothoff | Category | bank (demonstrator) => py bank (demonstrator, obsolete) |
| 2023-12-03 01:23 | Christian Grothoff | Category | py bank (demonstrator, obsolete) => obsolete componet |
| 2023-12-11 20:08 | Florian Dold | Category | obsolete componet => obsolete component |
