View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008190 | Taler | libeufin-nexus | public | 2024-01-22 14:52 | 2024-03-20 12:08 |
| Reporter | Antoine A | Assigned To | Antoine A | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
| Summary | 0008190: Error recovery strategy when ingesting EBICS files | ||||
| Description | When ingesting EBICS files, we may encounter errors, such as a loss of connection to the database. As some EBICS documents are ephemeral, the bank will only serve them once. When an EBICS download is requested, we need to acknowledge receipt with a status code that can be used to signal our inability to process these files. We need to check whether not sending the acknowledgement or responding with an error code will consume the ephemeral files or whether we need another solution on our side, and use this logic to stop losing them as we are doing now. | ||||
| Tags | No tags attached. | ||||
| related to | 0006402 | acknowledged | Antoine A | handle disrupted EBICS transactions |
| child of | 0008365 | closed | Christian Grothoff | package and upload libeufin 0.10 to ftp and stable Debian/Ubuntu server |
|
|
The response with an error code consumes ephemeral files. Not sending a confirmation of receipt puts our session in a special state where we get EBICS_PROCESSING_ERROR until the end of the EBICS transaction, but the ephemeral files are not consumed. If we can handle this error state by aborting the transaction, we might have a good primitive for handling errors. |
|
|
The old plan was to run a special fetch once a day with a specified start range to recover missed files in the event of failure. This doesn't work for ephemeral files, but could still be useful for notification files. |
|
|
Erattum: returning status code 1 in the receipt message prevent consumption of ephemeral files. I was led astray because we support both EBICS 2.5 and 3 and I only changed the status code for EBICS 3 whereas we only retrieve HACs using EBICS 2.5. Receipt message status code seems to be the cleanest solution. |
|
|
Fixed in 5837035a2e5679f529196ae85bc041d695a69176 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-01-22 14:52 | Antoine A | New Issue | |
| 2024-01-22 14:52 | Antoine A | Status | new => assigned |
| 2024-01-22 14:52 | Antoine A | Assigned To | => Antoine A |
| 2024-01-22 15:12 | Antoine A | Target Version | 0.10 => 0.9.4 |
| 2024-01-22 17:55 | Christian Grothoff | Target Version | 0.9.4 => 0.10 |
| 2024-01-31 11:39 | Antoine A | Note Added: 0021111 | |
| 2024-01-31 14:36 | Antoine A | Note Edited: 0021111 | |
| 2024-02-10 00:27 | Christian Grothoff | Relationship added | child of 0008365 |
| 2024-02-12 18:18 | Antoine A | Note Added: 0021256 | |
| 2024-02-12 19:02 | Antoine A | Note Added: 0021258 | |
| 2024-02-13 08:19 | Antoine A | Status | assigned => resolved |
| 2024-02-13 08:19 | Antoine A | Resolution | open => fixed |
| 2024-02-13 08:19 | Antoine A | Note Added: 0021268 | |
| 2024-02-28 19:12 | Florian Dold | Target Version | 0.10 => 0.9.4 |
| 2024-03-07 20:50 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2024-03-07 20:51 | Christian Grothoff | Status | resolved => closed |
| 2024-03-20 12:08 | Antoine A | Relationship added | related to 0006402 |
