View Issue Details

IDProjectCategoryView StatusLast Update
0006258Talerlibeufin-nexuspublic2024-04-15 21:32
ReporterFlorian Dold Assigned ToAntoine A  
PriorityhighSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
Target Version0.10Fixed in Version0.10 
Summary0006258: Track outgoing transaction status
DescriptionWe 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.
TagsNo tags attached.


related to 0008205 closedAntoine A Consider merging the fetch and submit commands 
child of 0008365 closedChristian Grothoff package and upload libeufin 0.10 to ftp and stable Debian/Ubuntu server 


Antoine A

2024-03-05 18:13

developer   ~0021691

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.

Antoine A

2024-03-12 11:52

developer   ~0021855

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.

Antoine A

2024-03-12 23:04

developer   ~0021880

Fixed in 105c74223be2a21aa0cf1aba25d36f460cddec4a

Issue History

Date Modified Username Field Change
2020-05-24 13:55 Florian Dold New Issue
2020-11-10 12:02 MS Target Version => 0.9.3
2023-04-13 20:26 Florian Dold Project libeufin => Taler
2023-04-13 20:26 Florian Dold Category nexus => General
2023-04-13 21:36 Florian Dold Category General => libeufin-nexus
2023-04-23 19:37 Florian Dold Target Version 0.9.3 => 0.10
2023-04-23 19:38 Florian Dold Assigned To => MS
2023-04-23 19:38 Florian Dold Status new => assigned
2023-12-22 15:07 Christian Grothoff Assigned To MS => Antoine A
2024-01-22 15:10 Antoine A Target Version 0.10 => 0.9.4
2024-01-22 16:05 Antoine A Summary parse HAC for better reliability => Track outgoing transaction status
2024-01-22 16:05 Antoine A Description Updated
2024-01-22 16:15 Antoine A Relationship added related to 0008205
2024-01-27 01:09 Christian Grothoff Relationship added child of 0008273
2024-01-29 15:22 Antoine A Priority normal => high
2024-01-29 15:22 Antoine A Target Version 0.9.4 => 0.10
2024-01-30 00:42 Christian Grothoff Severity minor => major
2024-02-10 00:26 Christian Grothoff Relationship added child of 0008365
2024-02-10 00:28 Christian Grothoff Relationship deleted child of 0008273
2024-03-05 18:13 Antoine A Note Added: 0021691
2024-03-12 11:52 Antoine A Note Added: 0021855
2024-03-12 23:04 Antoine A Status assigned => resolved
2024-03-12 23:04 Antoine A Resolution open => fixed
2024-03-12 23:04 Antoine A Note Added: 0021880
2024-04-09 13:11 Christian Grothoff Fixed in Version => 0.10
2024-04-15 21:32 Christian Grothoff Status resolved => closed