xpay: "Could not create payment onion: path too long!" on BOLT12 offers with large embedded TLVs (has FIXME)

[vincenzopalazzo]

Summary

When using xpay (and the surrounding payment plugins: renepay, askrene) to pay certain BOLT12 offers that carry large amounts of embedded data in their TLVs, xpay fails during onion construction with:

Could not create payment onion: path too long!

(with RPC error code 209 / PAY_UNSPECIFIED_ERROR).

The failure originates here:

https://github.com/ElementsProject/lightning/blob/master/plugins/xpay/xpay.c (around the do_inject function)

onion = create_onion(tmpctx, attempt, effective_bheight);
/* FIXME: Handle this better! */
if (!onion) {
    payment_give_up(aux_cmd, attempt->payment, PAY_UNSPECIFIED_ERROR,
        "Could not create payment onion: path too long!");
    return command_still_pending(aux_cmd);
}

The underlying cause is create_onionpacket(...) returning NULL when sphinx_path_payloads_size(sp) > ROUTING_INFO_SIZE.

Observed symptoms

• The BOLT12 offers in question contain long invoice / offer metadata (hundreds of bytes of extra TLV data for payout tracking / recipient verification). This inflates the final serialized onion far beyond what a "normal length" route would use.
• Route selection still proposes paths that later fail at the onion creation step.
• In the same payment attempts we also saw many plugin-cln-renepay failures with code=202 "Malformed error reply" and very large onionreply blobs.
• The node in question has very low channel count (only 2 active channels), which makes longer routes more common and the size limit easier to hit.
• The error was surfaced to end users via a higher-level plugin (cln4go-plugin doing custom "ocean-pay" logic) during real production Lightning payout processing.

Steps to reproduce (conceptual)

1. Have a node with limited channels.
2. Attempt to pay a BOLT12 offer (lni1... / lno1...) whose encoded invoice/offer contains substantial extra TLV data.
3. xpay / the payment attempt reaches create_onion → size check fails.

Expected behavior

• Either the route finder (askrene + xpay/renepay) should account for the final serialized onion size (including extra BOLT12 TLVs) when selecting paths, or
• xpay should handle the failure more gracefully (try a shorter route / more parts / clearer error with hop count + payload size, etc.), and
• the error message returned to the caller / user should be more actionable than the current generic "path too long".

Version / environment

• Observed on a custom/modded build based on v26.04 (and v25 on another instance)
• Using xpay, renepay, askrene, plus custom BOLT12 handling on top (cln4go-plugin)
• Full log excerpts and the exact failing offer (with tracking ID in the offer description) available if needed for reproduction.

Additional context

This was discovered while debugging a user-facing payout error on an experimental Ocean.xyz Lightning node (el.ocean.xyz).

The FIXME: Handle this better! comment suggests this case was already known to be suboptimal.

[vincenzopalazzo]

Additional concrete data from production

Here is a real BOLT12 offer (lno1...) that was actively being paid when the "Could not create payment onion: path too long!" error occurred for the user tracking ID 39t2zYyrzjENbytRfvyKPZYSEgtGbuqHB5:

lno1pg6y7s69g98zq5rp09hh2arnypnx7u3qxvuhgvn6t9uhy7n2g48xy7t52fn8v72t2pd9j569va6ywcn4w9yyydgkyypyfllql3rz68uyqx7045kts7zlu8z8ckm8a3ll8edhghekptrezjq

Decoded by the cln4go-plugin (ocean-pay path) immediately before the failure:

offer_description: OCEAN Payouts for 39t2zYyrzjENbytRfvyKPZYSEgtGbuqHB5
offer_issuer_id: 0244ffe0fc462d1f8401bcfad2cb8785fe1c47c5b67ec7ff3e5b745f360ac79148
offer valid: true

At the exact moment of the **BROKEN** log entry (2026-05-20T08:42:51.349Z):

**BROKEN** plugin-cln4go-plugin: plugin generate an error: JSONRPCError: code=209, message=Could not create payment onion: path too long!, data=map[]

Multiple similar large BOLT12 invoices (lni1qqgtn28qhtk56g2uzmddyztjkz4f2z35fap52s2wypgxz7t0w468xgrxdaezqveewse85ktewfax532wvfuhg5nxweu5k5z6t9f52em5ga382u2ggg63vggzgnl7plzx950cgqdultfvhpu9lcwy03dk0mrl70jmw30nvzk8j9y... etc.) were being processed in parallel in the same payment group, all hitting the same size limit inside xpay → create_onion → create_onionpacket.

We have the full raw lni1... strings and the surrounding renepay "Malformed error reply" (code 202) logs if they would help for reproduction or for adding size-accounting logic in askrene/xpay.

This is a production payout flow (Ocean miners claiming rewards via user-published BOLT12 offers).

[rustyrussell]

This implies the blinded path is too large: either long, or encrypted_recipient_data is large. Your LLM slop is misleading.

Please give me an actual invoice which failed. This is extremely unusual, since 1300 bytes has always been plenty of room. There's not much we can do about it: it's hard to bias towards shorter routes more than we do, and may not help much anyway.

[vincenzopalazzo]

Ok this is the invoice

 {
    "bolt12": "lni1qqgtn28qhtk56g2uzmddyztjkz4f2z35fap52s2wypgxz7t0w468xgrxdaezqveewse85ktewfax532wvfuhg5nxweu5k5z6t9f52em5ga382u2ggg63vggzgnl7plzx950cgqdultfvhpu9lcwy03dk0mrl70jmw30nvzk8j9y9ypqpupuqq4qqtqss82dkr3nk3j2fkresk32pmtjjqpv8y9gn62vnz5d8r5gc378yg5glt9757s69g98zqmrfva58gmnfdenjqurp09hh2apqwf6kumnfdenjqct5yp3xcmmrdvsxqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvp3893rwepnvscrvc34xfjrvwfnvv6rye34v93xxwpcxcen2ef38qenxvmrxd3kzwfjxqcxqgrpwssxsetfva58ggrq8y6nqvfkx4s2pxqzgnl7plzx950cgqdultfvhpu9lcwy03dk0mrl70jmw30nvzk8j9y0qs8hwu99keyfl82zg4940t7aed3xgf62p5ckdyljfeqmm69elp6qlmer7zcqlrq9pcud30afzm5g34wyfnagfl9ynps2fpj7h9dy382dz",
    "destination": "0244ffe0fc462d1f8401bcfad2cb8785fe1c47c5b67ec7ff3e5b745f360ac79148",
    "payment_hash": "8a5b133e7d11c431302f30903a66a4e61f6780b49381eb4ecb2879355e2d8b5e",
    "status": "failed",
    "created_at": 1779266530,
    "amount_sent_msat": 0,
    ...
  }

This is extremely unusual, since 1300 bytes has always been plenty of room. There's not much we can do about it: it's hard to bias towards shorter routes more than we do, and may not help much anyway.

We are getting this pretty often with the new implementation of CLN with the following distribution: 592 occurrences of the exact error are in the experimental node's log

Summary of occurrences (last month / all in the log)
• Total: 592
• Date range: 2026-05-05 → 2026-05-21 (all of them; none earlier in the searchable log for this exact BROKEN string)
• Distribution (by date):
• 2026-05-05: 12
• 2026-05-06: 11
• 2026-05-07: 8
• 2026-05-08: 47
• 2026-05-09: 29
• 2026-05-10: 13
• 2026-05-11: 49
• 2026-05-12: 10
• 2026-05-13: 8
• 2026-05-14: 9
• 2026-05-15: 15
• 2026-05-17: 20
• 2026-05-18: 29
• 2026-05-19: 75
• 2026-05-20: 179 (peak day)
• 2026-05-21: 78

All errors are logged by the custom plugin-cln4go-plugin ("ocean-pay") as:

BROKEN plugin-cln4go-plugin: plugin generate an error: JSONRPCError: code=209, message=Could not create payment onion: path too long!, data=map[]

Telling the AI doing some analysis of the logs I got the following yCategorization by implementation (the offers being paid)
100% of the 592 errors (exact count match) are payments to BOLT12 offers issued by Lexe.app users / hosted nodes.

Evidence from the log (decoded offers right before the errors):
• offer_issuer:lexe.app
• offer_issuer_id:03796b10a19d2ab62455af4a0e4b92a827c7fca97b3a4c694893ce05cccd6a5945 (and a few other Lexe issuer/blinded-path node IDs, e.g. 03c6ff1ce9e35a1cd916826eaee3398330ddc45695b86d8ca2266d4353b4fc7592)
• The offers contain Lexe's characteristic blinded paths + issuer metadata TLVs.

No other implementations appear in the 592 recent errors in any significant volume. Earlier in the log (Feb–Mar 2026) there were similar ocean-pay attempts to the same Lexe offers (sometimes failing for other reasons like "no peers"), but the specific code=209 path too long BROKEN logging only appears from May 5 onward (coinciding with heavier payout volume + the long block-hash payer_notes).

[Lagrang3]

@vincenzopalazzo, looking at the logs you may find the paths used by those xpay executions.
Could you check the length of the paths computed by getroutes?

[vincenzopalazzo]

@Lagrang3 Thanks for the pointer.

I looked at the debug log on the experimental node around the 592 code=209 "Could not create payment onion: path too long!" events from the cln4go-plugin (ocean-pay) flow.

Short answer:
The routes returned by getroutes/askrene for the failing payments to lexe.app BOLT12 offers were typically 7–9 hops long (including the final blinded path leg).

Details:

• Lexe offers use 2-hop blinded paths (confirmed via decode offer output in the same log).
• askrene often returned MPP sets where some flows had 6–7 real hops + the 2-hop blinded segment.
• These are exactly the ones that later blew up in xpay at onion creation time once the large final TLV (Lexe issuer metadata + blinded data + our payer_note containing the full block hash + height) was added.

I opened a cross-linked issue on the Lexe side as well:
lexe-app/lexe-public#77

Happy to paste more complete Flow X/Y: excerpts or the exact route JSON blobs if useful. Just let me know how much detail you want.

[vincenzopalazzo]

I asked Claude to make a simulation of the path finding, and probably it's lexicographic for some amount along the path to find the amount is too long https://gist.github.com/vincenzopalazzo/c8f9f4a5d0349ffdd0ee75bc4c4467a2

Looks like the path for that payment is up to 9 hops!

So, probably the CLN error is misleading (or not optimised for this case), but the path is so long for a transaction between two LSPs that it should be unacceptable these days, and probably there is nothing that we can do outside of improving the error message?

[TheBlueMatt]

Hmm, is it possible in the pathfinding algorithm to add a hard cap on the number of hops as an algorithm input (based on blinded path size)? I'd have to refresh my memory on how the algorithm works but as blinded paths become more popular this might be a more common issue.

[rustyrussell]

OK, the invoice above is truncated (it claims to have 154 bytes of blinded path, but there are only 99 bytes left).

But assuming it's accurate, I'd say it's not an absurd amount of data (I was wondering if someone was trying to put 1kb in there!). So this looks like a real problem, which surprises me!

So, yes, having askrene implement "maxlen", and having xpay calculate approx what length it can handle, would help.

How askrene does this limit is harder! Obviously it can trim any nodes further away than the limit, but that still leaves the possibility of returning longer paths (A may have a channel with C, but the channels via B are better...).

Even if it has to loop internally to meet the requirements, that would allow better explanations.