View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008205 | Taler | libeufin-nexus | public | 2024-01-22 15:15 | 2024-03-07 19:53 |
| Reporter | Antoine A | 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 | normal | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
| Summary | 0008205: Consider merging the fetch and submit commands | ||||
| Description | Currently the submit command submits pending transactions without knowing if they succeed, and the fetch command just fetches the final states of the transactions without tracking the status of the payments. We need to fetch incoming transactions if we're going to bounce malformed payments and we need to fetch to check if the submit was successful, so I don't see any reason to separate the two commands. Having a single command will simplify the deployment and administration of libeufin-nexus. | ||||
| Additional Information | I plan to use the following logic: - Retrieve incoming transactions and the final state of outgoing transactions (camt.054 and camt053?) - Fail fast if EBICS download failed due to HTTP or protocol failure - Ingest incoming transactions, boucing malformed transactions - Update the status of outgoing transactions, defining their final state - Retrieve CustomerPaymentStatusReport and HAC logs (pain.002) - Fail fast if EBICS download failed due to HTTP or protocol failure - Update the status of outgoing transactions, defining their final state in the event of failure - Submit pending transactions in batch in a single file (pain.001) - Fail fast if EBICS download failed due to HTTP or protocol failure - Retrieve HAC logs in a loop for fast feedback, wait until all pending orders have failed or been confirmed, or until a delay has elapsed | ||||
| Tags | No tags attached. | ||||
| related to | 0006258 | closed | Antoine A | Track outgoing transaction status |
| child of | 0008273 | closed | Florian Dold | package and upload libeufin 0.9.4 to ftp and stable Debian/Ubuntu server |
| One reason to separate them is that in some emergencies, you may want one but not the other. For example, when going out of business, you might disable 'fetch'. Or when there is a security issue, you may want to disable 'submit' but not 'fetch'. But, I guess this could be done with --disable-submit or something similar, that hacks into your main event loop. Another reason might eventually be performance: running multiple services (possibly on multiple hosts) to do the respective jobs (possibly in parallel). A third reason might be credentials and minimization of attack surface. Given separate credentials for submit and fetch, the code of the fetch job would have no access to the submit credentials. More critically, if one direction fails, that probably shouldn't block processing the other direction. Like if I cannot wire funds to merchants right now, that should NOT block customers from withdrawing funds! (And vice versa.). Finally, it is usually good to simply do one EBICS interaction, then one matching DB interaction, or one DB interaction and then one matching EBICS interaction (and ideally no subsequent DB interaction!). Doing a long sequence to me just suggests many more things that could go wrong. In fact, I'd rather see many independent different fetch jobs (camt53, camt.54, pain.02, HAC logs ...) and possibly even different submit jobs (pain.01, ???) each with very simple logic and very simple failure scenarios (and clear logs) than one complex state machine. Using DB notify/subscribe it should also be easy to trigger just the right one(s), so for example after submitting the pain01, you could do a DB notify to trigger the job that fetches the pain02. None of these are "hard" reasons not to do this, but please consider each when redesigning the system. | |
| We have chosen not to merge the commands. We will keep `libeufin-nexus ebics-submit` to submit all current transactions and `libeufin-nexus ebics-fetch` to fetch all documents. Additional subcommands will be added to `ebics-fetch` to allow you to choose which document to fetch. We can close this issue when libeufin-nexus has its own debian target so that we can add new services for fetch sub-commands in the future. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-01-22 15:15 | Antoine A | New Issue | |
| 2024-01-22 15:15 | Antoine A | Status | new => assigned |
| 2024-01-22 15:15 | Antoine A | Assigned To | => Antoine A |
| 2024-01-22 15:15 | Antoine A | Relationship added | related to 0006258 |
| 2024-01-22 15:18 | Antoine A | Additional Information Updated | |
| 2024-01-22 15:45 | Christian Grothoff | Note Added: 0020956 | |
| 2024-01-22 16:55 | Christian Grothoff | Target Version | 0.9.4 => 0.10 |
| 2024-01-24 14:23 | Antoine A | Target Version | 0.10 => 0.9.4 |
| 2024-01-27 00:09 | Christian Grothoff | Relationship added | child of 0008273 |
| 2024-01-30 12:55 | Antoine A | Note Added: 0021092 | |
| 2024-02-12 17:09 | Antoine A | Status | assigned => informing |
| 2024-02-12 17:09 | Antoine A | Resolution | open => fixed |
| 2024-03-07 19:53 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2024-03-07 19:53 | Christian Grothoff | Status | informing => closed |