View Issue Details

IDProjectCategoryView StatusLast Update
0008752Talerlibeufin-nexuspublic2024-08-28 23:31
ReporterFlorian Dold Assigned ToAntoine A  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.13Fixed in Version0.13 
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.

Relationships

has duplicate 0006402 closedAntoine A handle disrupted EBICS transactions 

Activities

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.

Antoine A

2024-07-08 19:16

developer   ~0022798

Fixed in b1d1a04590c18b57668b564fb91feb8af5a7d3c0
Sadly we always get EBICS_PROCESSING_ERROR and we cannot provide a better error message

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
2024-07-08 19:16 Antoine A Status assigned => resolved
2024-07-08 19:16 Antoine A Resolution open => fixed
2024-07-08 19:16 Antoine A Note Added: 0022798
2024-07-09 16:43 Christian Grothoff Product Version => git (master)
2024-07-09 16:43 Christian Grothoff Fixed in Version => 0.13
2024-07-09 16:43 Christian Grothoff Target Version 0.14 => 0.13
2024-07-30 17:24 Antoine A Relationship added has duplicate 0006402
2024-08-28 23:31 Christian Grothoff Status resolved => closed