Error pops up on xpay: We couldn't quite afford it, we need to send <#> msat more for fees: please submit a bug report

[lightningcheckout]

Issue and Steps to Reproduce

Running version: v24.11.1
When I try to pay 266266sats to a private node, the payment is failing over and over again with the following error in the log.

**BROKEN** plugin-cln-askrene: \"lnbits:pay#604917/cln:xpay-as-pay#243154/cln-xpay:getroutes#971/cln:getroutes#243495\": We couldn't quite afford it, we need to send 1127msat more for fees: please submit a bug report!

On de different tries the fees are changing.

To exactly the same node, the following amounts were succesfull:

• 130920sats
• 70192sats
• 22262sats

The liquidity on both sides is fine.

If needed the logs are available and can be shared.

[Lagrang3]

Thanks for the report!

This was meant to be a very rare corner case.
I admit the current implementation is fragile in many different points.
Let me see if I can work around this.

[lightningcheckout]

No problem, if it's a rare corner case perhaps not the most critical to fix.
If you can give some insights in what is actually going wrong and how I can try to work around it, could also be of help.

[Lagrang3]

If I remember correctly, this happens if some channel along the most desired route (the cheapest or most likely)
has a low HTCL_MAX value such that it is enough to forward the payment amount but not the amount + fees.
We use to redistribute the amounts among different routes, but if there is a single route then we panic.

To solve this manually you could exclude the bad channel.
Unfortunately we have manual exclude in renepay and pay but not yet in xpay.
Also you would need to know where the routing went wrong. So we need to give more information
to the user when this kind of problem happens.

[Lagrang3]

If you use xpay directly instead of pay through xpay-handle-pay you may exclude channels using the layer interface.

The useful commands are for example:

cli askrene-create-layer myexcluded
cli -k askrene-update-channel layer=myexcluded short_channel_id_dir="123x1122x222/0" enabled=false

and then

cli -k xpay invstring="ln..." layers="[myexcluded]"

[Lagrang3]

No problem, if it's a rare corner case perhaps not the most critical to fix. If you can give some insights in what is actually going wrong and how I can try to work around it, could also be of help.

renepay does not (I hope) have this problem because it will do a rework of the route computation
for the remaining amount. So another workaround could be: try with xpay, and if it doesn't work, fallback
to renepay.

[lightningcheckout]

Tnx for the explanation! It's hard to intervene since it's used within an automated process. Let's see if this happens often or is just a rare case indeed before I change the process.

I didn't see it before in renepay payments btw.

But in general I'm happy with xpay, first day in weeks without failed payouts in the morning 💯

[lightningcheckout]

To confirm. today I had this error again, same destination and amount also like the previous one.
I tried with renepay manually and in that scenario, the payment went through (like @Lagrang3 expected).