View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006691 | Taler | mechant backend | public | 2021-01-12 15:18 | 2024-01-12 14:04 |
| Reporter | Florian Dold | Assigned To | Florian Dold | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.8 | Fixed in Version | 0.8 | ||
| Summary | 0006691: merchants implements duplicate retry logic for exchange connection handles | ||||
| Description | Exchange 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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. |
| 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 |
| 2024-01-12 14:04 | Christian Grothoff | Category | merchant backend API (C) => mechant backend |
