From a754af99833bb2c43fa275f8069494a98c97fa27 Mon Sep 17 00:00:00 2001 From: Christian Decker Date: Mon, 13 Jul 2020 17:33:14 +0200 Subject: [PATCH] ld: We might not have a failing channel if localfail and sendonion 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. --- lightningd/pay.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/lightningd/pay.c b/lightningd/pay.c index 4d416d293..e100d3b6d 100644 --- a/lightningd/pay.c +++ b/lightningd/pay.c @@ -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;