View Issue Details

IDProjectCategoryView StatusLast Update
0006009Talerbank (demonstrator)public2020-03-31 16:04
ReporterChristian GrothoffAssigned ToFlorian Dold 
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Versiongit (master) 
Target Version0.6Fixed in Version0.6 
Summary0006009: bank's /admin/add/incoming is not idempotent
DescriptionWhen 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.
TagsNo tags attached.


Marcello Stanisci

2019-12-24 13:29

manager   ~0015219

Here it would be VERY useful to know which data (a JSON field supposedly? Which one?) was not liked by the aggregator!

Christian Grothoff

2019-12-24 14:08

manager   ~0015220

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.

Florian Dold

2020-01-27 21:42

manager   ~0015300

Has been implemented in the python bank (and fakebank) a while ago.

Issue History

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