mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2025-03-03 10:46:58 +01:00
Code Issues Projects Releases Wiki Activity

ld: We might not have a failing channel if localfail and sendonion

Browse source 
This happens to be an edge case with the way we use `sendonion` in
MPP. `sendonion` does not attempt to recover the route even if we supply the
shared secrets (it'd require us to map forwarding channels to the nodes etc),
so `failnode` will always be unset, unless it is the first hop, which gets
stored. This is not a problem if it weren't for the fact that we don't store
the partial route, consisting solely of the channel leading to the first hop,
therefore the assertion that either both are NULL or both aren't fails on the
first hop.

This went unnoticed since with MPP we have more concurrent payments in flight,
increasing the chances of a exhausted first hop considerably.
This commit is contained in:
Christian Decker 2020-07-13 17:33:14 +02:00
parent a3610d66ac
commit 212a3c5ec5
1 changed files with 9 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
lightningd/pay.c
View file

@ -701,15 +701,20 @@ static struct command_result *wait_payment(struct lightningd *ld,
} else {
/* Parsed onion error, get its details */
assert(failnode);
assert(failchannel);
fail = tal(tmpctx, struct routing_failure);
fail->erring_index = failindex;
fail->failcode = failcode;
fail->erring_node =
tal_dup(fail, struct node_id, failnode);
fail->erring_channel =
tal_dup(fail, struct short_channel_id, failchannel);
fail->channel_dir = faildirection;
if (failchannel) {
fail->erring_channel = tal_dup(
fail, struct short_channel_id, failchannel);
fail->channel_dir = faildirection;
} else {
fail->erring_channel = NULL;
}
/* FIXME: We don't store this! */
fail->msg = NULL;