View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008645 | Taler | libeufin-nexus | public | 2024-03-15 15:05 | 2024-04-15 19:32 |
| 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 | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.10 | Fixed in Version | 0.10 | ||
| Summary | 0008645: FIx cashin idempotency when conversion is enabled | ||||
| Description | The netzbon deployment encountered an error I've seen twice before where ingesting the same incoming EBICS transaction a second time triggers a unique conflict on the talerable_incoming_transactions table in the database. I didn't trigger this error in regular libeufin-nexus tests because the SQL query used ON CONFLICT to handle this problem correctly and efficiently. However, when conversion is enabled, a trigger is set BEFORE insertion and therefore before the ON CONFLICT check... As this trigger is not idempotent, we need to check idempotency before inserting a row. I've also added a test case for this in the integration test suite. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-03-15 15:05 | Antoine A | New Issue | |
| 2024-03-15 15:05 | Antoine A | Status | new => assigned |
| 2024-03-15 15:05 | Antoine A | Assigned To | => Antoine A |
| 2024-03-15 15:06 | Antoine A | Target Version | => 0.10 |
| 2024-03-15 15:06 | Antoine A | Status | assigned => informing |
| 2024-03-15 15:06 | Antoine A | Resolution | open => fixed |
| 2024-03-15 15:06 | Antoine A | Note Added: 0021936 | |
| 2024-04-09 11:11 | Christian Grothoff | Fixed in Version | => 0.10 |
| 2024-04-15 19:32 | Christian Grothoff | Status | informing => closed |