View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011323 | Taler | exchange | public | 2026-03-31 07:16 | 2026-04-01 15:23 |
| Reporter | vecirex | Assigned To | vecirex | 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 | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Summary | 0011323: Cut-off delays get applied to / inherited by another instance if they share one bank account in common | ||||
| Description | Just reproduced using TOPS/CHF stage and private taler.hacktivism.ch instance, both using exchange.taler-ops.ch, that is on two instances running on completely different infrastructures and with different versions of the taler-merchant, such that this must be an exchange issue. Highly problematic is, that the correct cut-off dates are only shown for the instance they were set on; the other instance continues to display the old ones -- in the UI at least, but behaves differently than shown. This should be fixed as to not have instances inheriting cut-off delays because of a common bank account (e.g., IBAN no.). | ||||
| Steps To Reproduce | 0. Add one common bank account to an instance A and B, both using the same exchange. 1. Add a second bank account to an instance B, do all three KYC Auths (1 for A, 2 for B). 2a. Change the payment delay to 1s for instance A, having only one bank account; making a payment practically impossible, transaction gets cancelled ("already claimed"). 2b. Also in instance B, it won't be possible to do any payment, because payment delay is too short; this without touching instance's B settings at all. Instance B can even be running on another site, by someone else. 2c. This sticks true for B, even if another bank account is defined for wire transfers using the transfers location: $site/webui/#/transfers; this makes it for B not transparent what's going on / why payments eventually don't work at all (or if they work, with other delays not visible and not set oneself). | ||||
| Tags | No tags attached. | ||||
| More -v on the reproduction steps. | |
| This report makes no sense. It's architecturally impossible, the exchange doesn't even see the payment delays. Also, please don't invent new terms, we never talk about "cut-off delays". There is no such things. We have payment deadlines, refund deadlines, and wire deadlines. | |
| After comms w/ CG here: apparently, it's not possible to use the same IBAN twice for payments, if configured on different instances, which would actually be the bug... I thought I saw this working, but will check again and report here what I find. | |
| Seems rather to be related to IBAN reusage not yet working, cf. https://bugs.gnunet.org/view.php?id=11328#c28356. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-03-31 07:16 | vecirex | New Issue | |
| 2026-03-31 07:16 | vecirex | Relationship added | related to 0011212 |
| 2026-03-31 07:23 | vecirex | Summary | Cut-off delays get applied to / inherited by a another instance if they share one bank account in common => Cut-off delays get applied to / inherited by another instance if they share one bank account in common |
| 2026-03-31 07:24 | vecirex | Steps to Reproduce Updated | |
| 2026-03-31 07:28 | vecirex | Steps to Reproduce Updated | |
| 2026-03-31 07:28 | vecirex | Note Added: 0028321 | |
| 2026-03-31 07:29 | vecirex | Steps to Reproduce Updated | |
| 2026-03-31 20:36 | Christian Grothoff | Note Added: 0028345 | |
| 2026-03-31 20:36 | Christian Grothoff | Assigned To | => vecirex |
| 2026-03-31 20:36 | Christian Grothoff | Status | new => feedback |
| 2026-04-01 12:37 | vecirex | Note Added: 0028351 | |
| 2026-04-01 12:37 | vecirex | Status | feedback => acknowledged |
| 2026-04-01 15:23 | vecirex | Status | acknowledged => closed |
| 2026-04-01 15:23 | vecirex | Resolution | open => no change required |
| 2026-04-01 15:23 | vecirex | Note Added: 0028357 |