clboss/Boss/Mod/XMoveFunds
Ken Sedgwick 7500a2344b
Some checks are pending
Code Base Sanity Check / tests (push) Waiting to run
Code Base Sanity Check / coverage (push) Waiting to run
Code Base Sanity Check / build-clang (push) Waiting to run
XMoveFunds: never disable_node our own node on a NODE-level failure
In a circular rebalance the destination is ourselves, so a NODE-level onion
failure (failcode & 0x2000) at the closing hop is attributed to erring_node ==
self. accumulate_failure_feedback's node-level branch called disable_node(
erring_node) unconditionally, so it disabled OUR OWN node in the persistent
clboss-xrebalance layer. askrene then treats every one of our channels as a
disabled source -- getroutes fails with 205 "source has disabled N of N
channels, leaving capacity only 0msat" -- and because disabled_nodes never
ages, every subsequent rebalance is locked out permanently (fee budget is
irrelevant). Observed on prod1: one end-of-route node failure took out all 73
source channels at once.

Guard the node-level branch: if erring_node == self_id, return without
disabling. Mirrors the self-loop guard FundsMover already has on the clboss
layer. A node-level failure blamed on us (we are the paying destination, so we
would accept) is a mis-attribution anyway and nothing about our own node should
be disabled.

Recovery for an already-poisoned layer (no askrene un-disable-node exists):
askrene-remove-layer clboss-xrebalance ; askrene-create-layer clboss-xrebalance true

Logging/behavior otherwise unchanged.
2026-06-04 13:25:19 -07:00
..
Claimer.cpp XMoveFunds: implement sendpay execution path 2026-05-31 20:46:58 -07:00
Claimer.hpp XMoveFunds: implement sendpay execution path 2026-05-31 20:46:58 -07:00
Main.cpp XMoveFunds: never disable_node our own node on a NODE-level failure 2026-06-04 13:25:19 -07:00
Main.hpp XMoveFunds: scaffold the manual-trigger rebalance primitive 2026-05-31 14:10:56 -07:00