View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008752 | Taler | libeufin-nexus | public | 2024-04-17 18:12 | 2024-08-28 21:31 |
| Reporter | Florian Dold | Assigned To | Antoine A | 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 | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.13 | Fixed in Version | 0.13 | ||
| Summary | 0008752: interrupted EBICS upload/download transactions lead to multiple minutes of stalling for that order type | ||||
| Description | An EBICS upload/download transaction consists of multiple HTTP requests. If for some reason (network error, exception while processing the payload, ...) not all requests for one EBICS transaction are made, the EBICS server will *refuse* new requests for that order type, until either: * the remaining requests to upload/download/abort the old transaction are mare * a timeout (about 10 minutes, implementation-dependent) occurs To avoid this, we would have to store the status of started EBICS transactions in our database. This is only possible sometimes, as we need the TransactionID from the request that starts the transaction. If the response to that request is lots, all bets are off and we have to wait for the timeout. In that case, we should at least log an appropriate error message. We need to experiment which error code we get in that case, as that's not clear from the specification. The error we get from the GLS ebics host is technical=EBICS_OK,bank=EBICS_PROCESSING_ERROR, which doesn't make too much sense. | ||||
| Tags | No tags attached. | ||||
| Or maybe it *is* actually possible even when the first response gets lost, as the request contains a user-selected nonce that the server might use to check for resumption/idempotency. | |
| Fixed in b1d1a04590c18b57668b564fb91feb8af5a7d3c0 Sadly we always get EBICS_PROCESSING_ERROR and we cannot provide a better error message | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-04-17 18:12 | Florian Dold | New Issue | |
| 2024-04-17 18:12 | Florian Dold | Status | new => assigned |
| 2024-04-17 18:12 | Florian Dold | Assigned To | => Antoine A |
| 2024-04-17 18:21 | Florian Dold | Note Added: 0022269 | |
| 2024-05-06 08:07 | Antoine A | Target Version | 0.11 => 0.14 |
| 2024-07-08 17:16 | Antoine A | Status | assigned => informing |
| 2024-07-08 17:16 | Antoine A | Resolution | open => fixed |
| 2024-07-08 17:16 | Antoine A | Note Added: 0022798 | |
| 2024-07-09 14:43 | Christian Grothoff | Product Version | => git (master) |
| 2024-07-09 14:43 | Christian Grothoff | Fixed in Version | => 0.13 |
| 2024-07-09 14:43 | Christian Grothoff | Target Version | 0.14 => 0.13 |
| 2024-07-30 15:24 | Antoine A | Relationship added | has duplicate 0006402 |
| 2024-08-28 21:31 | Christian Grothoff | Status | informing => closed |