[bug]: getting `FAILURE_REASON_NO_ROUTE` when I should get `FAILURE_REASON_INSUFFICIENT_BALANCE`

[ZZiigguurraatt]

I have the following network

       SAT           TA
dave <----> edward <----> frank

I'm trying to send a payment from frank to dave that should fail, but I'm getting FAILURE_REASON_NO_ROUTE when I should get FAILURE_REASON_INSUFFICIENT_BALANCE. Here is the output of my test script:

frank sending Asset1 via edward and dave receiving 360 of sats
MaxAllowableFee: 11
r_hash: "\005\370\tU\202\336\203*j \347^W\025>\221\276\277\020\026%\322\241\245\377-\030sQ\375\250\227"
payment_request: "lnbcrt3600n1pnm92svpp5qhuqj4vzm6pj563qua09w9f7jxlt7yqkyhf2rf0l95v8x50a4ztsdqqcqzzsxqyz5vqsp5ypll905eu7zsupnfysheq4vgtj0dvvd47a5flw5fadw3vuyzhfrq9qxpqysgqrmlwqhjxmr2javkawc247wunlv4dedsacml926r3yje0ju0upquh2xf4wqlujlmq7fzp2hwgj3y9ysa30nnzfvm7lgaujz2f5ucsv4sq0yu9mv"
add_index: 1
payment_addr: " \177\362\276\231\347\205\016\006i$/\220U\210\\\236\3261\265\367h\237\272\211\353]\026p\202\272F"

r_hash: 05f8095582de832a6a20e75e57153e91bebf101625d2a1a5ff2d187351fda897

invoice asset_amount: 36000
invoice num_satoshis: 360

invoice route_hints: []

expected route: ['frank', 'edward', 'dave']
actual channel capacities:
(✔) (A) cap: 100000 sat, frank->[bal: 50354 sat|res: 1062 sat|spend: 44762 sat], edward->[bal: 46566 sat|res: 1000 sat|spend: 41036 sat], commit_fee: 2420
(x) (A) cap: 200000000 Asset1, frank->[bal: 36000 Asset1], edward->[bal: 199964000 Asset1]
(✔) (A) cap: 1000000 sat, edward->[bal: 50361 sat|res: 10000 sat|spend: 35831 sat], dave->[bal: 946169 sat|res: 10000 sat|spend: 931639 sat], commit_fee: 2810

accepted_sell_order {
  peer: "027f6d233721377f16caf3ffe5205ea832056fb65b2a236181d0a1dde1fec8ebd4"
  id: "/Xyu\251a\350\365\362\321C\304\265\361\327\213fE\037w\365\000\036\256\365\201\0278\216\377\202\311"
  scid: 17690446342972736201
  asset_amount: 37100
  bid_asset_rate {
    coefficient: "10000000000"
  }
  expiry: 1739762223
  min_transportable_msat: 354010
}

payment_result {
  payment_hash: "05f8095582de832a6a20e75e57153e91bebf101625d2a1a5ff2d187351fda897"
  value: 360
  creation_date: 1739762188
  payment_preimage: "0000000000000000000000000000000000000000000000000000000000000000"
  value_sat: 360
  value_msat: 360000
  payment_request: "lnbcrt3600n1pnm92svpp5qhuqj4vzm6pj563qua09w9f7jxlt7yqkyhf2rf0l95v8x50a4ztsdqqcqzzsxqyz5vqsp5ypll905eu7zsupnfysheq4vgtj0dvvd47a5flw5fadw3vuyzhfrq9qxpqysgqrmlwqhjxmr2javkawc247wunlv4dedsacml926r3yje0ju0upquh2xf4wqlujlmq7fzp2hwgj3y9ysa30nnzfvm7lgaujz2f5ucsv4sq0yu9mv"
  status: IN_FLIGHT
  creation_time_ns: 1739762188660154833
  payment_index: 1
  first_hop_custom_records {
    key: 65538
    value: "/Xyu\251a\350\365\362\321C\304\265\361\327\213fE\037w\365\000\036\256\365\201\0278\216\377\202\311"
  }
}

payment_result {
  payment_hash: "05f8095582de832a6a20e75e57153e91bebf101625d2a1a5ff2d187351fda897"
  value: 360
  creation_date: 1739762188
  payment_preimage: "0000000000000000000000000000000000000000000000000000000000000000"
  value_sat: 360
  value_msat: 360000
  payment_request: "lnbcrt3600n1pnm92svpp5qhuqj4vzm6pj563qua09w9f7jxlt7yqkyhf2rf0l95v8x50a4ztsdqqcqzzsxqyz5vqsp5ypll905eu7zsupnfysheq4vgtj0dvvd47a5flw5fadw3vuyzhfrq9qxpqysgqrmlwqhjxmr2javkawc247wunlv4dedsacml926r3yje0ju0upquh2xf4wqlujlmq7fzp2hwgj3y9ysa30nnzfvm7lgaujz2f5ucsv4sq0yu9mv"
  status: FAILED
  creation_time_ns: 1739762188660154833
  payment_index: 1
  failure_reason: FAILURE_REASON_NO_ROUTE
  first_hop_custom_records {
    key: 65538
    value: "/Xyu\251a\350\365\362\321C\304\265\361\327\213fE\037w\365\000\036\256\365\201\0278\216\377\202\311"
  }
}

status: FAILED
failure_reason: FAILURE_REASON_NO_ROUTE

Please make the error message right so people can know what is going on without having to print so much debug information like I have to do above.

[Roasbeef]

The way lnd's path finding works, if a route is deemed to have too low of a probability of success, it's skipped. If no routes are above the min threshold, then it concludes that there're no available routes.

So in your case, you can look at the actual full streaming output (using TrackPayment). It likely takes that route first, gets the insufficient balance, then goes to try again, and realizes that there're no available routes.

[ZZiigguurraatt]

The streaming responses from SendPaymentV2 are shown above. What I don't get is how a payment was able to try to go IN_FLIGHT if there was nothing in the local balance to lock up in an HTLC?

[ZZiigguurraatt]

Actually, re-looking at the above output, it looks like I had exactly 36,000 assets in the channel. My (x) seems to only indicate if I have more than enough assets, not exactly enough. Maybe it tried to put a 0 fee payment in flight since it could try to do that, but since that did not work, the peer rejected it?

Wondering if we should have a different error that comes back if it can't find a route AND it might be because it also doesn't have enough funds to reach our fee_limit (which above is set to MaxAllowableFee: 11) and fully attempt through all routes. Probably this would be an LND issue though, not a tapd issue?

[levmi]

Yes, I believe changing the response for pathfinding errors would be on the LND side. Closing this here, if you want, can be re-opened on LND repo.