View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0007872Talerwallet-corepublic2023-06-27 14:342024-03-07 20:49
Reportersebasjm Assigned ToFlorian Dold  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.9.4Fixed in Version0.9.4 
Summary0007872: WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE does not always return feeGapEstimate
Descriptioncoins:
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"
          }
        }
      }
    }
TagsNo tags attached.

Activities

Florian Dold

2023-06-27 20:03

manager   ~0020309

Last edited: 2023-06-27 20:03

 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?

sebasjm

2023-06-28 15:00

developer   ~0020312

> 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.

Florian Dold

2023-06-28 15:46

manager   ~0020313

Yeah, sounds good, but I'd call it maxRawInstructedAmount since instructed amount is ambiguous. I'll implement this.

Florian Dold

2024-03-07 00:07

manager   ~0021743

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

Issue History

Date Modified Username Field Change
2023-06-27 14:34 sebasjm New Issue
2023-06-27 14:34 sebasjm Status new => assigned
2023-06-27 14:34 sebasjm Assigned To => Florian Dold
2023-06-27 20:03 Florian Dold Note Added: 0020309
2023-06-27 20:03 Florian Dold Note Edited: 0020309
2023-06-27 20:03 Florian Dold Assigned To Florian Dold => sebasjm
2023-06-27 20:03 Florian Dold Status assigned => feedback
2023-06-28 15:00 sebasjm Note Added: 0020312
2023-06-28 15:00 sebasjm Assigned To sebasjm => Florian Dold
2023-06-28 15:46 Florian Dold Note Added: 0020313
2024-03-07 00:07 Florian Dold Note Added: 0021743
2024-03-07 00:07 Florian Dold Status feedback => resolved
2024-03-07 00:07 Florian Dold Resolution open => fixed
2024-03-07 11:09 Christian Grothoff Fixed in Version => 0.9.4
2024-03-07 11:09 Christian Grothoff Target Version 0.11 => 0.9.4
2024-03-07 20:49 Christian Grothoff Status resolved => closed