View Issue Details

IDProjectCategoryView StatusLast Update
0006691Talermerchant backend API (C)public2021-08-24 16:23
ReporterFlorian Dold Assigned ToFlorian Dold  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.8Fixed in Version0.8 
Summary0006691: merchants implements duplicate retry logic for exchange connection handles
DescriptionExchange handles already implement retry and network timeouts. The merchant implements another retry layer on top of that.

This can cause some unwanted interactions. For example, the exchange handles network timeouts, and increases the network timeout after subsequent timeout issues. When the merchant implements its own retry logic, the exchange can't dynamically adjust the timeouts anymore.

The only retries that the merchant should handle are retries for /wire, since the exchange doesn't retry those.
TagsNo tags attached.

Activities

Christian Grothoff

2021-01-16 22:46

manager   ~0017363

I think you are confused about the two cases. The libtalerexchange does timeout/retry on network-level failures. The taler-merchant-httpd_exchanges.c has two other types of 'retry':
1) version incompatibility; so we got a reply, but the version is incompatible or reply was malformed (but still "200 OK"). libtalerexchange does not auto-retry those as far as I can see. Here the merchant uses the RELOAD_DELAY (2 minutes + backoff).
2) client-driven retry. Usually we re-download keys based on the HTTP expiration header (exchange-controlled). That's done by libtalerexchange. But IF we get coins/denominations that claim to be from an exchange but we are unaware of, it is possible that the exchange revoked a key and issued coins in a new replacement denomination. So in this case ,the merchant 'forces' a re-download. Alas, that is rate-limited (FORCED_RELOAD_DELAY, 15 minutes + client-trigger).

So neither of those are really covered by libtalerexchange. They are also not the per-request timeouts we talked about for /pay.

My conclusion: it is actually fine as-is.

Florian Dold

2021-01-16 23:29

manager   ~0017364

Discussed offline: It's fine as-is.

The exchange in some situations does some retries that the merchant *also* does, but that's not really an issue.

Issue History

Date Modified Username Field Change
2021-01-12 15:18 Florian Dold New Issue
2021-01-12 15:18 Florian Dold Status new => assigned
2021-01-12 15:18 Florian Dold Assigned To => Christian Grothoff
2021-01-16 22:46 Christian Grothoff Note Added: 0017363
2021-01-16 22:46 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2021-01-16 22:46 Christian Grothoff Status assigned => feedback
2021-01-16 23:29 Florian Dold Status feedback => resolved
2021-01-16 23:29 Florian Dold Resolution open => fixed
2021-01-16 23:29 Florian Dold Note Added: 0017364
2021-07-30 13:56 Christian Grothoff Fixed in Version => 0.8
2021-07-30 13:59 Christian Grothoff Target Version => 0.8.1
2021-07-30 14:01 Christian Grothoff Target Version 0.8.1 => 0.8
2021-08-24 16:23 Christian Grothoff Status resolved => closed