View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011894 | Taler | merchant backend | public | 2026-10-28 10:13 | 2026-10-29 21:07 |
| Reporter | sebasjm | Assigned To | Christian Grothoff | 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 | unable to reproduce |
| Status | informing | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 1.6 | Fixed in Version | 1.6 | ||
| Summary | 0011894: wrong deposit_fee calc on high fee coins | ||||
| Description | I found this bug in # taler-merchant-httpd --version taler-merchant-httpd v1.6.23 present in master but is getting very hard to reproduce, maybe impossible, and not sure why. It happened with 2 orders in my setup. There the backend tries to decide whether the exchange has already wired the money for an order. It computes the amount it expects to have received as: expect_total = contract_amount - refund_amount + deposit_fees_refunded_total - deposit_fees_total That calculation is wrong when the deposit fee were larger than the merchant max_fee and the customer covered the excess. In that case the merchant should really receive: contract_amount - min(deposit_fees_total, max_fee) ========================= what i found is that the bugs lays in not yet wired "if (! gorc->wired)" path [1] but not sure which sequence of depositcheck / reconciliation / wirewatch steps are needed. I created, played and failed to create a bash script to recreate the issue. So instead I added a unit test. In my setup: * there was no manual update in the database * only a single exchange involved (maybe two exchanges would trigger this easily) * older version and other bugs were found that maybe put the db in this state * I change the denomination set from version A to version B because version A had deposit fee NUMIS:1 to 0. That's the only uncommon change, these 2 orders were before that (https://exchange.taler.ar/keys) so maybe this code path is not triggerable on master? Still the calculation is wrong. my db | order_id | contract amount | `max_fee` | total deposit fees | net the merchant should receive | |---|---|---|---|---| | `2026.274-10WTG8GQFJHTT` | `NUMIS:1.2` | `NUMIS:0.2` | `NUMIS:2.0` (coins 2.0+1.0, fees 1.0+1.0) | `NUMIS:1.0` | | `2026.275-R2HN9HX1TR524` | `NUMIS:0.1` | `NUMIS:0.1` | `NUMIS:1.0` (coin 1.0, fee 1.0) | `NUMIS:0.0` | [1] src/backend/taler-merchant-httpd_get-private-orders-ORDER_ID.c:1740 | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-10-28 10:13 | sebasjm | New Issue | |
| 2026-10-28 10:13 | sebasjm | Status | new => assigned |
| 2026-10-28 10:13 | sebasjm | Assigned To | => Christian Grothoff |
| 2026-10-28 11:12 | sebasjm | Assigned To | Christian Grothoff => sebasjm |
| 2026-10-28 11:12 | sebasjm | Note Added: 0030158 | |
| 2026-10-28 11:12 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2026-10-28 11:12 | sebasjm | Status | assigned => feedback |
| 2026-10-29 21:07 | Christian Grothoff | Status | feedback => informing |
| 2026-10-29 21:07 | Christian Grothoff | Resolution | open => fixed |
| 2026-10-29 21:07 | Christian Grothoff | Fixed in Version | => 1.6 |
| 2026-10-29 21:07 | Christian Grothoff | Note Added: 0030172 | |
| 2026-10-29 21:07 | Christian Grothoff | Target Version | git (master) => 1.6 |