View Issue Details

IDProjectCategoryView StatusLast Update
0008752Talerlibeufin-nexuspublic2024-05-06 10:07
ReporterFlorian Dold Assigned ToAntoine A  
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Target Version0.14 
Summary0008752: interrupted EBICS upload/download transactions lead to multiple minutes of stalling for that order type
DescriptionAn 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.
TagsNo tags attached.


Florian Dold

2024-04-17 20:21

manager   ~0022269

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.

Issue History

Date Modified Username Field Change
2024-04-17 20:12 Florian Dold New Issue
2024-04-17 20:12 Florian Dold Status new => assigned
2024-04-17 20:12 Florian Dold Assigned To => Antoine A
2024-04-17 20:21 Florian Dold Note Added: 0022269
2024-05-06 10:07 Antoine A Target Version 0.11 => 0.14