fix(lnd): SendPaymentV2 needs an explicit fee budget — absent means ZERO

v1.8.9's move to Router.SendPaymentV2 shipped without fee_limit_sat, and the v2 route treats an ABSENT fee limit as zero allowed fees. Every real route carries a routing fee (the 2-hop route here: 1.5 sats), so the pathfinder rejected them all and the wallet answered "No route to the recipient" on EVERY send — all day, on healthy channels with plenty of liquidity both ways. The router debug log makes it unambiguous: wallet payment (v1.8.9 backend): fee_limit=0 mSAT -> no route same payment by hand (lncli --fee_limit=100): fee_limit=100000 mSAT -> settles in 0.65s My earlier "pipeline verified" claim was wrong — the manual lncli verification set a fee limit by hand and masked this exact bug. The 400k that succeeded this morning went through the pre-update backend on the pre-update LND. Payments now carry lncli's own default budget — the payment amount (100%), preferring the payer-supplied amount for zero-value invoices and the invoice's own amount otherwise, with a nominal floor so the limit can never be zero. Unit-pinned so it cannot regress.
2026-09-01 18:42:37 -04:00
parent 0d0e2e243a
commit 1ca002661b
3 changed files with 37 additions and 0 deletions
@@ -369,6 +369,7 @@ init()
                  <span class="text-xs text-white/40">September 2, 2026</span>
                </div>
                <div class="space-y-3 text-sm text-white/80 pl-3 border-l border-white/10">
+                  <p><strong>Lightning sends work again.</strong> v1.8.9's move to LND 0.21's supported payment route shipped without a fee budget, and the API treats a missing one as zero allowed fees — so every wallet send failed "No route to the recipient" all day, on perfectly healthy channels. Payments now carry a proper fee budget and a test keeps it from ever regressing.</p>
                  <p><strong>A channel that drops its peer link now heals itself — on every node.</strong> Restarting LND (an app update, a reboot, container churn) can leave a channel's peer connection down for hours while both endpoints keep the channel flagged disabled in the routing graph: the node looks perfectly healthy, the wallet shows balance, and every payment in either direction fails "no route to the recipient". The daemon now watches the channel graph as desired state — every open channel should have a live peer — and reconnects any that don't. Nodes without LND are untouched; an unreachable peer is retried gently.</p>
                  <p><strong>The Lightning wallet says what's actually wrong, instead of "you have no channel".</strong> Trying to send while a channel you just opened was still confirming — or when all its balance sits on the far side — produced a modal claiming you had no channel at all, and payment routing failures even showed the receiving copy. The gate now reads your real channel list: a confirming channel gets "it unlocks automatically once confirmed, nothing is needed from you", a far-side balance gets "you can receive, but there's nothing to send right now", and only a genuinely channel-less node is sent to open one.</p>
                </div>