Looking at the lightningd/pay.c code, it seems we have two paths to go through for failure. If the faliure is local, we immediately call json_pay_failed. Otherwise we extract the failure code from the failing hout and then call json_pay_failed. I think the "report route failure to gossipd" should be in json_pay_failed instead of payment_failed.

Plan:

Add a double cost_multiplier to struct node_connection. In bfg_one_edge, multiply fee by this cost_multiplier field. Initialize cost_multiplier to 1.0.
Add a gossip_inform_failed_route message which accepts a variadic array of struct route_hop, from lightningd to gossipd. The handler for this message searches for each struct node_connection via get_connection_by_scid and get_channel_direction, then adds a small constant to the cost_multiplier.
Keep the array of struct route_hop in the struct pay_command (modulo @rustyrussell 's plan to get rid of it in favor of wallet_payment), stealing it into the pay_command. Modify json_pay_success to accept a struct pay_command and tal_free the route. Modify json_pay_failed to send gossip_inform_failed_route to gossipd with the route and tal_free it afterwards.

Notice that the above plan does not look at failcode, even though the comment check_for_routing_failure(i, sender, failure_code) suggests that we should. The thing is that even permanent failures we cannot be certain which channel/node actually failed on a long route. So the best we can do is simply to weaken all channels along the route indiscriminately.

pay needs to hand failures back to gossipd for re-routing #550

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions