Invoice contains route hint to closed channel

[JssDWt]

This invoice was created today lnbc4325770n1pnzlxm2dq6gf5hgcm0d9hzq4rjv9h8xen9wgpp5j2v472f5m903s6jn9t2klf7ku5pa4lr6vh209fqkr8mdm406j6esxqy9gcqsp5yvmskp053rtutlr4gtfpe7ugz5jlf2kg27f49kxw42h5934qndwq9qrsgqcqzysrzjqfj2v2jrqltsrsz2g6v5ee04xga3eg5vsrrxku7xx8dukzvs6m5r2vmp84sqhsljrsqqqqlgqqqqqzsqjqh2ppqm7c3say8n2vfcwtu0q9rekydrhqzjv7cqq6k5yxjlm5u6cpj9e8lr8gw90j9nnulc6gaw8ytgvz26nzxtzxsjf86056dsl0x2qqk9jut9 for node 036d6d6e23f13e2f0033cc582b67b6d5b4ae0e78e192ea8338e7ca8fa03ce4e1ba

It contains a route hint to the channel
funding tx: d9efda963ae52266ca4c47276036da76328e31870ee160bc0a9d8a79017c055a:0
short_channel_id: 839435x2669x0
remote alias: 3367229x6294467x61980

That channel was closed 13 days ago.

I assume the user's node was not up-to-date with the chain when creating this invoice, hence didn't know about the closed channel. In this case the invoice was tied to an onchain swap with the Breez SDK, but turns out to be unpayable, because of the closed channel.

[cdecker]

Indeed it looks like we got extremely unlucky, as the following snippet shows:

2024-04-29T15:06:53+02:00 {} stdout: DEBUG   plugin-gl-plugin-internal: Read response from JSON-RPC: {\"id\":0,\"jsonrpc\":\"2.0\",\"result\":{\"bolt11\":\"lnbc4325770n1pnzlxm2sp5yvmskp053rtutlr4gtfpe7ugz5jlf2kg27f49kxw42h5934qndwqpp5j2v472f5m903s6jn9t2klf7ku5pa4lr6vh209fqkr8mdm406j6esdq6gf5hgcm0d9hzq4rjv9h8xen9wgxqy9gcqcqzys9qxpqysgqruqn66f3vxwgv3kahwgs0vvcvdnvlmylgxj97q7xm5wx42x0crds3078y5xshag4gf9c593ylpes6mejnuw7yaye9n3ctje6me8535qph08ncd\",\"created_index\":3,\"expires_at\":1714568813,\"payment_hash\":\"92995f2934d95f186a532ad56fa7d6e503dafc7a65d4f2a41619f6ddd5fa96b3\",\"payment_secret\":\"23370b05f488d7c5fc7542d21cfb881525f4aac8579352d8ceaaaf42c6a09b5c\",\"warning_capacity\":\"Insufficient incoming channel capacity to pay invoice\"}}
...
2024-04-29T15:06:53+02:00 {} stdout: DEBUG   0264a62a4307d701c04a46994ce5f5323b1ca28c80c66b73c631dbcb0990d6e835-connectd: Connected out, starting crypto
2024-04-29T15:06:53+02:00 {} ESC[2m2024-04-29T13:06:53.275551ZESC[0m ESC[35mTRACEESC[0m ESC[2mgl_nodeletESC[0mESC[2m:ESC[0m Plugin bus message PluginNotification { notification_type: Some(RpcCall(RpcCall { methodname: "/greenlight.Node/RespondHsmRequest" })) }
2024-04-29T15:06:54+02:00 {} stderr: [2024-04-29T13:06:54Z INFO  gl_subdaemon::gossipd] This node is post-multiplexing, not returning a peer handler
2024-04-29T15:06:55+02:00 {} stdout: DEBUG   lightningd: Adding block 839469: 00000000000000000002f62830c6b1b92fc73b83b1067edcb6dad09b5ee54a2d
2024-04-29T15:06:55+02:00 {} stdout: DEBUG   0264a62a4307d701c04a46994ce5f5323b1ca28c80c66b73c631dbcb0990d6e835-chan#1: Got UTXO spend for d9efda963ae52266ca4c47276036da76328e31870ee160bc0a9d8a79017c055a:0: 60a87148b96448f4f94ef928e411676a49489eb43a8c2d1d4f417007912b178f
2024-04-29T15:06:55+02:00 {} stdout: UNUSUAL 0264a62a4307d701c04a46994ce5f5323b1ca28c80c66b73c631dbcb0990d6e835-chan#1: Peer permanent failure in CHANNELD_NORMAL: Funding transaction spent

So the invoice was created less than 2 seconds before we learned about the channel being closed. This is a symptom of Blockchain lag (#347) and should be mostly addressed. Notice that we can't quite exclude this from happening in rare occasions, but we should add all available channels, so a single closed one should not be a big deal. If it turns out to happen more frequently we'll have to add the closed channel detection to the routing server and check with it before including it in an invoice. Notice that even in this case, the temporal separation between invoice creation and payment, this may always happen, i.e., channel was open while the invoice was created, but closing before it is being paid, and we need to be robust to handle this correctly in the LN implementation itself.

Closing as it was addressed.