discovery+switch: apply zero forwarding policy updates in-memory as w… #3439
Conversation
wpaulino
requested review from
cfromknecht,
halseth,
Roasbeef and
wpaulino
as code owners
wpaulino
requested review from
joostjager
and removed request for
Roasbeef,
cfromknecht and
halseth
valentinewallace
force-pushed
the
fix-zero-fwding-policy-updates
branch
from
41b80b5 to
906ffc4
Compare
| } | ||
| // Finally, we'll apply the set of channel policies to the target | ||
| // channels' links. | ||
| r.server.htlcSwitch.UpdateForwardingPolicies(chanPolicies) |
There was a problem hiding this comment.
With this change, the gossiper becomes even more a requirement to update a local link policy. In my model of how this should work, it should be the other around. The link primarly determines what the policy is and gossiper just gossips. Maybe local channel parameter validation should happen in the link and when all is checked and updated, we just extract the current settings from the link and gossip it around.
It seems that something isn't right in the separation of concerns. Perhaps the part of gossiper that handles validation and storage for local channels should be extracted to a new object.
There was a problem hiding this comment.
I'm not opposed to it, but going this route seems like a much bigger change for a bug that's causing routing failures at the moment. This change is pretty small in that it's just exposing the state the gossiper is already acting on. I understand that doing so will just make the separation of concerns worse though.
There was a problem hiding this comment.
Ok. I also realize now that links are not always up, so there must be an independent data store somewhere that stores the local policy.
The only thing I am still thinking about: if we'd just make all policy parameters mandatory for the rpc call (including minhtlc and maxhtlc), would this feedback path of final policies from gossiper still be necessary? If the policy is complete, the links (the ones that are up) and gossiper can be updated independently.
There was a problem hiding this comment.
That's true, but I think it would be best if none of them were mandatory, meaning a user could only specify the ones they want to be updated. That makes me want to make max htlc non-mandatory and lay groundwork for making the other fields non-mandatory as well.
This approach also has the advantage of not breaking the RPC interface for existing users of UpdateChannelPolicy.
There was a problem hiding this comment.
Discussed offline. Still not convinced about the business case for adding this granularity on the rpc level. Because the UpdateChannelPolicy is currently buggy with zero values, I think there is an opportunity to make the fields mandatory now without it being considered as really breaking (it was broken already). But as discussed, leaving further development out of this pr's scope.
| } | ||
| // Finally, we'll apply the set of channel policies to the target | ||
| // channels' links. | ||
| r.server.htlcSwitch.UpdateForwardingPolicies(chanPolicies) |
There was a problem hiding this comment.
Discussed offline. Still not convinced about the business case for adding this granularity on the rpc level. Because the UpdateChannelPolicy is currently buggy with zero values, I think there is an opportunity to make the fields mandatory now without it being considered as really breaking (it was broken already). But as discussed, leaving further development out of this pr's scope.
valentinewallace
force-pushed
the
fix-zero-fwding-policy-updates
branch
2 times, most recently
from
3b84b5c to
7a3341b
Compare
valentinewallace
force-pushed
the
fix-zero-fwding-policy-updates
branch
2 times, most recently
from
9f27767 to
9423045
Compare
…ell as on disk In this commit, we fix a bug where if a user updates a forwarding policy to be zero, the update will be applied to the policy correctly on-disk, but not in-memory. We solve this issue by having the gossiper return the list of on-disk updated policies and passing these policies to the switch, so the switch can assume that zero-valued fields are intentional and not just uninitialized.
valentinewallace
force-pushed
the
fix-zero-fwding-policy-updates
branch
from
9423045 to
8ce7f82
Compare
…ell as on disk
In this commit, we fix a bug where if a user updates a forwarding policy to be
zero, the update will be applied to the policy correctly on-disk, but not
in-memory.
We solve this issue by having the gossiper return the list of on-disk updated
policies and passing these policies to the switch for updates, so the switch can assume
that zero-valued fields are intentional and not just uninitialized.