the FAILURE_REASON_NO_ROUTE in allow_self_payment payment process.

[SevenLiquor]

question

I attempted to use the assets to pay for an invoice that was specifically for myself,there is only one intermediate node in the routing.
During the payment process, I used "allow_self_payment" and received the error message "FAILURE_REASON_NO_ROUTE".
And not every time will it fail; occasionally it will succeed in payment.

test procedures

1.Create two nodes, A and B, and use the same rfq oracle.same buy price and sell price
2.Open two channels, an asset channel and a BTC channel,and make sure they can use it properly
3.Use A to create a BTC invoice, and use A's assets to pay for it.
4. use the "allow_self_payment" option,outgoingChanId is assetChannelId

result

1.Payment failed and received FAILURE_REASON_NO_ROUTE
2.Not every attempt will fail, but if one fails, the next attempt will also fail unless I change the price and use another invoice.

logs

1.Log of Node B

2025-08-01 16:18:58.398 [INF] RFQS: Would reject sell request: no suitable buy offer, but ignoring for now
2025-08-01 16:18:58.745 [INF] LNWL: Verifying new musig2 sig for session=7553d175d0326b031ed2c55af74933be9b7869206c1337d40357a039b5f28dcc, nonce=NoncePair(verification_nonce=02d870841996378fb33e90476add8f4acc343b157d0211831165d16cc39d0e9d83038db7d48023817422af1aa9366bc2e78c6f1c2f1f2b3488a681fffc875f9fe1e2, signing_nonce=024ccc88fb42186500f42d4955a106c8270aa5fa9917c55e15bc9d20e014719a6903515dd05067df4069500425138a0a90d08f8702af34c17a29a09e4b7594213457)
2025-08-01 16:18:58.772 [INF] LNWL: Generating new musig2 sig for session=06910ed20048dda1e0cd84595e4842c45a7a962b8fe01013e35795091615db55, nonces=NoncePair(verification_nonce=038af67d5f5d3dd10bf37e046f91eefb88d605cc5bdca10e10d13a632cdf03c8b003c9b149518ab200514e870db3599dfad65ef6c367575553db97894e11e9b23a10, signing_nonce=029b6ddbf945c2d6dbf0aea9a6188afae7e2886d5aed51a2efcedc1da53a97c7ba02690aba58aeb1b7013f70a80617feb6e9fb81592f8a7ce790b55238fd88c37511)
htlc is AssetPurchasePolicy 107
2025-08-01 16:18:58.831 [ERR] HSWC: same incoming and outgoing channel
2025-08-01 16:18:58.831 [ERR] HSWC: Unhandled error while reforwarding htlc settle/fail over htlcswitch: same incoming and outgoing channel
2025-08-01 16:18:58.844 [INF] LNWL: Generating new musig2 sig for session=8e282c2cd46ef6a786181c25a76bbb295952714c63de939b2e190ccff7f27f9a, nonces=NoncePair(verification_nonce=02532e89b1c54ba03d355bb368f4c579d96b7c1e3eab53c32e8ff5de5ad7867cce03fb18b6417cfeca09fca981d3548fcfc188043b7ba23b7ef73660753576fc8549, signing_nonce=023425b143b5cc631214b8f7c9387e28f866cf27fc845de84e63dcf9bc5418f35a023fb262ed6b9014f478f747c1f560e4530731cd9a26a90df5ce47a8633817118f)
2025-08-01 16:18:58.897 [INF] LNWL: Verifying new musig2 sig for session=a4aa9272491860b0fefd2bfc63e601b88c345d05bb46703135909af093efa493, nonce=NoncePair(verification_nonce=035307994d69f5e0582f4046dc9763c053bb43442ad2378ba01c9ee33f88bed7420257364d74b54a82154c56e1b383ffde63e927d94e578d889f004f32f6e70ab55a, signing_nonce=02d4badbd89474b30e9d463ac8a2a378f7f9fbb268909e3b94ffc1de028b244bed03499888976f1cc39a0dfa8eda8b41dcfaeefd04631c10fa974657cd4be5da9199)
2025-08-01 16:18:59.943 [INF] LITD: Handling gRPC request: /litrpc.Status/SubServerStatus
2025-08-01 16:19:10.069 [INF] LITD: Handling gRPC request: /litrpc.Status/SubServerStatus
2025-08-01 16:19:10.820 [INF] RFQS: Would reject sell request: no suitable buy offer, but ignoring for now
2025-08-01 16:19:20.088 [INF] LITD: Handling gRPC request: /litrpc.Status/SubServerStatus
2025-08-01 16:19:29.827 [INF] UNIV: Synchronizing with 1 federation members

Two consecutive payment failures,But only the first one made this mistake.

2025-08-01 16:18:58.831 [ERR] HSWC: same incoming and outgoing channel
2025-08-01 16:18:58.831 [ERR] HSWC: Unhandled error while reforwarding htlc settle/fail over htlcswitch: same incoming and outgoing channel

2.Log of Node A

2025-08-01 16:18:58.325 [INF] LITD: Handling gRPC request: /tapchannelrpc.TaprootAssetChannels/SendPayment
2025-08-01 16:18:58.568 [INF] RPCS: Got quote for 26026 asset units at 50050000.000 asset/BTC from peer 303338383639653936366361366231383265333239623637363538653434313761306466333335633061373231366238303233636462653038623466656333363561 with SCID 17592341028379974491
2025-08-01 16:18:58.712 [INF] LNWL: Generating new musig2 sig for session=9277e6b627d33f9b97da50a183ecdc2cd0c56840891bd1bd14bec2b51687a8c1, nonces=NoncePair(verification_nonce=02d870841996378fb33e90476add8f4acc343b157d0211831165d16cc39d0e9d83038db7d48023817422af1aa9366bc2e78c6f1c2f1f2b3488a681fffc875f9fe1e2, signing_nonce=024ccc88fb42186500f42d4955a106c8270aa5fa9917c55e15bc9d20e014719a6903515dd05067df4069500425138a0a90d08f8702af34c17a29a09e4b7594213457)
2025-08-01 16:18:58.803 [INF] LNWL: Verifying new musig2 sig for session=e70b264fef98d2905f64a2eceaf9c300f296851dfa5874e205d6836b64d7cd8a, nonce=NoncePair(verification_nonce=038af67d5f5d3dd10bf37e046f91eefb88d605cc5bdca10e10d13a632cdf03c8b003c9b149518ab200514e870db3599dfad65ef6c367575553db97894e11e9b23a10, signing_nonce=029b6ddbf945c2d6dbf0aea9a6188afae7e2886d5aed51a2efcedc1da53a97c7ba02690aba58aeb1b7013f70a80617feb6e9fb81592f8a7ce790b55238fd88c37511)
2025-08-01 16:18:58.862 [INF] LNWL: Verifying new musig2 sig for session=74ac90b4a18cfb02c5e7814db754b894a6ad22b0c73ca0c3285bde70a1672913, nonce=NoncePair(verification_nonce=02532e89b1c54ba03d355bb368f4c579d96b7c1e3eab53c32e8ff5de5ad7867cce03fb18b6417cfeca09fca981d3548fcfc188043b7ba23b7ef73660753576fc8549, signing_nonce=023425b143b5cc631214b8f7c9387e28f866cf27fc845de84e63dcf9bc5418f35a023fb262ed6b9014f478f747c1f560e4530731cd9a26a90df5ce47a8633817118f)
2025-08-01 16:18:58.878 [INF] LNWL: Generating new musig2 sig for session=8b3bb807795fce34f38e7e686f0b80d2ea957282d7ade03328a22ac3ebbce9c4, nonces=NoncePair(verification_nonce=035307994d69f5e0582f4046dc9763c053bb43442ad2378ba01c9ee33f88bed7420257364d74b54a82154c56e1b383ffde63e927d94e578d889f004f32f6e70ab55a, signing_nonce=02d4badbd89474b30e9d463ac8a2a378f7f9fbb268909e3b94ffc1de028b244bed03499888976f1cc39a0dfa8eda8b41dcfaeefd04631c10fa974657cd4be5da9199)
2025-08-01 16:18:58.921 [WRN] CRTR: Attempt 13011 for payment fbbdda3dc8ed7a2edf6b28ddd8ca41d6077c4432d099e74e5d1f07503b7f8af5 failed: TemporaryChannelFailure@1
2025-08-01 16:18:58.933 [WRN] CRTR: Failed to find route for payment fbbdda3dc8ed7a2edf6b28ddd8ca41d6077c4432d099e74e5d1f07503b7f8af5: unable to find a path to destination
2025-08-01 16:18:58.933 [WRN] CRTR: Marking payment fbbdda3dc8ed7a2edf6b28ddd8ca41d6077c4432d099e74e5d1f07503b7f8af5 permanently failed with no route: no_route
2025-08-01 16:18:58.946 [ERR] CRTR: No route found for payment fbbdda3dc8ed7a2edf6b28ddd8ca41d6077c4432d099e74e5d1f07503b7f8af5
2025-08-01 16:18:58.946 [WRN] CHDB: Payment(fbbdda3dc8ed7a2edf6b28ddd8ca41d6077c4432d099e74e5d1f07503b7f8af5): cannot register HTLC attempt: payment has already failed, current status: Failed
2025-08-01 16:18:58.947 [ERR] RPCS: [/tapchannelrpc.TaprootAssetChannels/SendPayment]: payment failed: FAILURE_REASON_NO_ROUTE
2025-08-01 16:18:58.947 [ERR] CRTR: Payment fbbdda3dc8ed7a2edf6b28ddd8ca41d6077c4432d099e74e5d1f07503b7f8af5 failed: no_route
2025-08-01 16:19:08.926 [INF] GRPH: Examining channel graph for zombie channels
2025-08-01 16:19:08.926 [INF] GRPH: Pruning 0 zombie channels
2025-08-01 16:19:09.039 [INF] UNIV: Synchronizing with 1 federation members
2025-08-01 16:19:09.040 [INF] UNIV: Fetching 0 roots
2025-08-01 16:19:09.040 [INF] UNIV: Obtained 0 roots from remote Universe server
2025-08-01 16:19:10.679 [INF] LITD: Handling gRPC request: /tapchannelrpc.TaprootAssetChannels/SendPayment
2025-08-01 16:19:10.927 [INF] RPCS: Got quote for 26026 asset units at 50050000.000 asset/BTC from peer 303338383639653936366361366231383265333239623637363538653434313761306466333335633061373231366238303233636462653038623466656333363561 with SCID 17754264516455055064
2025-08-01 16:19:10.961 [WRN] CRTR: Failed to find route for payment cfea4975651ed70a2671d7c3585d599c2fbc84e56170b5a140699f7f302541dc: unable to find a path to destination
2025-08-01 16:19:10.962 [WRN] CRTR: Marking payment cfea4975651ed70a2671d7c3585d599c2fbc84e56170b5a140699f7f302541dc permanently failed with no route: no_route
2025-08-01 16:19:10.975 [ERR] CRTR: No route found for payment cfea4975651ed70a2671d7c3585d599c2fbc84e56170b5a140699f7f302541dc
2025-08-01 16:19:10.975 [WRN] CHDB: Payment(cfea4975651ed70a2671d7c3585d599c2fbc84e56170b5a140699f7f302541dc): cannot register HTLC attempt: payment has already failed, current status: Failed
2025-08-01 16:19:10.976 [ERR] CRTR: Payment cfea4975651ed70a2671d7c3585d599c2fbc84e56170b5a140699f7f302541dc failed: no_route
2025-08-01 16:19:10.976 [ERR] RPCS: [/tapchannelrpc.TaprootAssetChannels/SendPayment]: payment failed: FAILURE_REASON_NO_ROUTE

other items

The payment command uses a code.

       //.......
	req := &tchrpc.SendPaymentRequest{
		AssetId:    assetIdByte,
		PeerPubkey: peerPubkey,
		PaymentRequest: &routerrpc.SendPaymentRequest{
			PaymentRequest:   invoice,
			TimeoutSeconds:   60,
			AllowSelfPayment: allowSelfPayment,
		},
	}
	req.PaymentRequest.OutgoingChanIds = []uint64{outgoingChanId}
	if feeLimitSat != 0 {
		req.PaymentRequest.FeeLimitSat = feeLimitSat
	} else {
		req.PaymentRequest.FeeLimitSat = 999999
	}
	stream, err := client.SendPayment(context.Background(), req)
    //........

When I used cmd to make the payment, this error rarely occurred. Maybe it has something to do with the code, but I'm unable to prove this theory.

[guggero]

Thanks for the details. So the problem here is TemporaryChannelFailure@1 from the point of view of the sender.
And the error for that on the node B is same incoming and outgoing channel as you correctly pointed out.

The reason for that is that node B will randomly pick any valid channel to forward an HTLC over to the destination node, because that's allowed as part of the "non-strict forwarding" policy of lnd.

What you can do is turn on lnd.allow-circular-route=true on node B to avoid the error.
Or, this is what we do in our integration tests, use a hop hint in the invoice to guide the pathfinding algorithm toward picking the correct channel: https://github.com/guggero/lightning-terminal/blob/b0e1d552d15ecbc23a77ab211d0fb63b782421a7/itest/litd_custom_channels_test.go#L4793

The CltvExpiryDelta, FeeBaseMsat and FeeProportionalMillionths should of course be the correct channel settings of the inbound policy from B toward A, not hard-coded example values as in our test.