View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006258 | Taler | libeufin-nexus | public | 2020-05-24 11:55 | 2024-04-15 19:32 |
| 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 | high | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.10 | Fixed in Version | 0.10 | ||
| Summary | 0006258: Track outgoing transaction status | ||||
| Description | We can have failures at four levels: - EBICS upload: these are errors when we upload pain.001 files to the EBICS server, they can be transient HTTP errors or a permanent EBICS protocol errors that we get when submitting. The HTTP error can be resolved by waiting or changing the configuration and the EBICS protocol error can be resolved by updating libeufin or changing the configuration, and then resubmitting the payments. - EBICS validation: these are errors when the EBICS server ingests files. We obtain them by retrieving the HAC logs (pain.002). They are ephemeral files available quickly (seconds) after submission. They are often temporary errors that can be resolved by modifying the configuration or updating libeufin, and then resubmitting the payments. - Bank error: these are errors when the bank tries to make the payment. We obtain them by retrieving the CustomerPaymentStatusReport (pain.002). These are sometimes ephemeral files, sometimes permanent, available a few minutes or a few hours after submission. These are permanent errors because no other payment with the same IDS can be made. - Payment error: when our bank issues the payment but the creditor's bank rejects it, we get a bounce transaction in the transaction log (camt.054 or camt.053). These are permanent files available a few hours or days after submission. They are permanent errors because no other payment with the same IDS can be made. (TODO still investigating how those errors take forms) For the HAC logs, we need the OrderDetail generated by the EBICS server during submission and for the other files, we need the full transaction identifier MessageIdentification.PaymentInformationIdentification.InstructionIdentification provided by us in the pain.001 file. | ||||
| Tags | No tags attached. | ||||
| related to | 0008205 | closed | Antoine A | Consider merging the fetch and submit commands |
| child of | 0008365 | closed | Christian Grothoff | package and upload libeufin 0.10 to ftp and stable Debian/Ubuntu server |
| We should distinguish between transient failures that should be retried, protocol failures that should be retried after an update, and bank failures that cannot be retried. | |
| With the variety of EBICS errors that can occur and the lack of error typing in Kotlin, I think we should have a simpler, less error-prone approach. All errors encountered during an EBICS upload transaction should be considered transient. They can be transport errors, HTTP errors, EBICS errors or protocol errors. As the transaction has failed, we can and should try again. Whenever we encounter an error during upload, we wait for the next execution, which is a very simple, stupid but effective way of exerting back-pressure in case the bank server rate limit us. If the error is a protocol error, we'll fail in loop at each tick and after updating libeufin-nexus, the transaction will be retried and succeed. There remains the problem of EBICS errors, which may be permanent but which we've never encountered before; it would be stupid to block the sending of other transactions because of them. Every time we submit a transaction, we should start by sending all the transactions that have never been sent, starting with the oldest by date of creation. Then, when they've all succeeded, we try to send the transactions that failed before, starting with the oldest by date of submission. If we never encounter an error, all transactions will be sent every time. In the opposite case, where some transactions fail but not others, transaction submission can be severely delayed by waiting unnecessarily for the next submission. We could choose to always send until N transactions fail if this becomes a problem in the future. All outgoing transactions failures found during ebics-fetch are considered permanent. We can add exceptions in the future when we have a better idea of which errors occur and which can be retried under real conditions if any. | |
| Fixed in 105c74223be2a21aa0cf1aba25d36f460cddec4a | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-05-24 11:55 | Florian Dold | New Issue | |
| 2020-11-10 11:02 | MS | Target Version | => 0.9.3 |
| 2023-04-13 18:26 | Florian Dold | Project | libeufin => Taler |
| 2023-04-13 18:26 | Florian Dold | Category | nexus => General |
| 2023-04-13 19:36 | Florian Dold | Category | General => libeufin-nexus |
| 2023-04-23 17:37 | Florian Dold | Target Version | 0.9.3 => 0.10 |
| 2023-04-23 17:38 | Florian Dold | Assigned To | => MS |
| 2023-04-23 17:38 | Florian Dold | Status | new => assigned |
| 2023-12-22 14:07 | Christian Grothoff | Assigned To | MS => Antoine A |
| 2024-01-22 14:10 | Antoine A | Target Version | 0.10 => 0.9.4 |
| 2024-01-22 15:05 | Antoine A | Summary | parse HAC for better reliability => Track outgoing transaction status |
| 2024-01-22 15:05 | Antoine A | Description Updated | |
| 2024-01-22 15:15 | Antoine A | Relationship added | related to 0008205 |
| 2024-01-27 00:09 | Christian Grothoff | Relationship added | child of 0008273 |
| 2024-01-29 14:22 | Antoine A | Priority | normal => high |
| 2024-01-29 14:22 | Antoine A | Target Version | 0.9.4 => 0.10 |
| 2024-01-29 23:42 | Christian Grothoff | Severity | minor => major |
| 2024-02-09 23:26 | Christian Grothoff | Relationship added | child of 0008365 |
| 2024-02-09 23:28 | Christian Grothoff | Relationship deleted | child of 0008273 |
| 2024-03-05 17:13 | Antoine A | Note Added: 0021691 | |
| 2024-03-12 10:52 | Antoine A | Note Added: 0021855 | |
| 2024-03-12 22:04 | Antoine A | Status | assigned => informing |
| 2024-03-12 22:04 | Antoine A | Resolution | open => fixed |
| 2024-03-12 22:04 | Antoine A | Note Added: 0021880 | |
| 2024-04-09 11:11 | Christian Grothoff | Fixed in Version | => 0.10 |
| 2024-04-15 19:32 | Christian Grothoff | Status | informing => closed |