View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007872 | Taler | wallet-core | public | 2023-06-27 12:34 | 2024-03-07 19:49 |
| Reporter | sebasjm | Assigned To | Florian Dold | 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 | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
| Summary | 0007872: WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE does not always return feeGapEstimate | ||||
| Description | coins: 1 x KUDOS:5 5 x KUDOS:2 1 x KUDOS:1 28 x KUDOS:0.1 balance material: 18.8 Calling `WalletApiOperation.CheckPeerPushDebit` with amount=18.8 I get feeGapEstimate: 0.36 which is right, and expected. BUT: Calling `WalletApiOperation.CheckPeerPushDebit` with amount=19 I get feeGapEstimate: 0 I expect to return feeGapEstimate: 0.36 OR: to return something that I can use to in `WalletApiOperation.CheckPeerPushDebit` maybe a workaround: if "CheckPeerPushDebit" fails then call again with balanceMaterial - feeGapEstimate. Then: 1.- amount=19 it will fail, and call 18.8 2.- amount=18.8 it will fail, and call 18.44 3.- amount=18.44 will work example of errors: with amount = 18.8 "details": { "code": 7027, "when": { "t_ms": 1687868248035 }, "hint": "Error (WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE)", "insufficientBalanceDetails": { "amountRequested": "KUDOS:18.8", "balanceAvailable": "KUDOS:18.8", "balanceMaterial": "KUDOS:18.8", "feeGapEstimate": "KUDOS:0.36", "perExchange": { "https://exchange.demo.taler.net/": { "balanceAvailable": "KUDOS:18.8", "balanceMaterial": "KUDOS:18.8", "feeGapEstimate": "KUDOS:0.36" } } } } with amount = 19 "details": { "code": 7027, "when": { "t_ms": 1687868876516 }, "hint": "Error (WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE)", "insufficientBalanceDetails": { "amountRequested": "KUDOS:19", "balanceAvailable": "KUDOS:18.8", "balanceMaterial": "KUDOS:18.8", "feeGapEstimate": "KUDOS:0", "perExchange": { "https://exchange.demo.taler.net/": { "balanceAvailable": "KUDOS:18.8", "balanceMaterial": "KUDOS:18.8", "feeGapEstimate": "KUDOS:0" } } } } | ||||
| Tags | No tags attached. | ||||
| As discussed in the Mumble meeting, I see this as the function conforming to its specification. The feeGapEstimate is only reported when the payment looks like it would be possible with the material amount, but is impossible because of extra fees. If the payment is "obviously not possible", there is no need to report the feeGapEstimate. It looks like you (@Sebastian) are using the output of this to compute the maximum amount that can be spent, right? If that's the case, I would propose that we have a separate wallet-core request for that. In case the CheckPeerPushDebit returns the insufficient balance error, the UI should just use this new request to show a nicer error message. Or alternatively, the WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE error details could always include some "maxAmountRaw" in it, so we don't have to make a separate request from the UI. What do you think? | |
| > Or alternatively, the WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE error details could always include some "maxAmountRaw" in it, so we don't have to make a separate request from the UI. This one is better. Maybe we should call it "maxInstructedAmount"? Because I expect this amount to be what the UI is going to suggest the user to be the max to call the operation again. So if I call the operation again (and no balance change in the middle) with instructedAmount = maxInstructedAmount the operation will succeed and use all the coins. | |
| Yeah, sounds good, but I'd call it maxRawInstructedAmount since instructed amount is ambiguous. I'll implement this. | |
| commit 7ba1d1f3351e58a331e99337afea0fbedb6eb828 (HEAD -> master, origin/master, origin/HEAD, dev/dold/wip) Author: Florian Dold <florian@dold.me> Date: Wed Mar 6 21:15:30 2024 +0100 refactor coin selection, report maxEffectiveSpendAmount | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-06-27 12:34 | sebasjm | New Issue | |
| 2023-06-27 12:34 | sebasjm | Status | new => assigned |
| 2023-06-27 12:34 | sebasjm | Assigned To | => Florian Dold |
| 2023-06-27 18:03 | Florian Dold | Note Added: 0020309 | |
| 2023-06-27 18:03 | Florian Dold | Note Edited: 0020309 | |
| 2023-06-27 18:03 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-06-27 18:03 | Florian Dold | Status | assigned => feedback |
| 2023-06-28 13:00 | sebasjm | Note Added: 0020312 | |
| 2023-06-28 13:00 | sebasjm | Assigned To | sebasjm => Florian Dold |
| 2023-06-28 13:46 | Florian Dold | Note Added: 0020313 | |
| 2024-03-06 23:07 | Florian Dold | Note Added: 0021743 | |
| 2024-03-06 23:07 | Florian Dold | Status | feedback => informing |
| 2024-03-06 23:07 | Florian Dold | Resolution | open => fixed |
| 2024-03-07 10:09 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2024-03-07 10:09 | Christian Grothoff | Target Version | 0.11 => 0.9.4 |
| 2024-03-07 19:49 | Christian Grothoff | Status | informing => closed |