Send ChannelManager messages out-of-band to ensure ordered delivery #217
Conversation
TheBlueMatt
force-pushed
the
2018-10-msg-resp-overhaul
branch
2 times, most recently
from
f3e5cc6 to
36ae7b8
Compare
|
Well if tests are still identical in behavior it shouldn't be too much a hustle to rebase other current PRs, I mean at least with mines after a really quick skim on diffs. So when ready go ahead and get it merge for 0.0.6. Will review new commits tomorrow. |
|
With head at b5cbc4e, I hit a crash with the fuzzer, but wasn't able to reproduce it twice (should learn honggfuzz I know will do it soon..) |
1 similar comment
|
With head at b5cbc4e, I hit a crash with the fuzzer, but wasn't able to reproduce it twice (should learn honggfuzz I know will do it soon..) |
Add retryable and error_code fields to PaymentFailed event Add RouteUpdate event ala lightningdevkit#217 containing msgs::HTLCFailChannelUpdate Move msgs::HTLCFailChannelUpdate from update_fail_htlc's return value to the payload of RouteUpdate fired inside fail_htlc_backwards_interanl Some fixes in decode_update_add_htlc_onion Move procesing onion failure to fail_htlc_backwards_internal Test for process_onion_failure
|
After discussion, the crash in question was a race in resetting the rng state across threads between the dummy test and the breakage test, this is an independent issue that may have just been exacerbated here, but should be fixed separately (by commenting out the dummy test by default). |
TheBlueMatt
force-pushed
the
2018-10-msg-resp-overhaul
branch
from
36ae7b8 to
aa7539e
Compare
TheBlueMatt
force-pushed
the
2018-10-msg-resp-overhaul
branch
from
aa7539e to
cd43181
Compare
TheBlueMatt
force-pushed
the
2018-10-msg-resp-overhaul
branch
from
cd43181 to
fbc42ad
Compare
TheBlueMatt
force-pushed
the
2018-10-msg-resp-overhaul
branch
4 times, most recently
from
df38048 to
470d9cc
Compare
Extend KeyStorage with delayed_payment_base_key and per_commitment_point to derive local_delayed private key
Move ChannelKeys into keysinterface for generate a set of it from master_seed and change return type to panic on bogus data
Drop channel_close_key from ChannelKeys
…nnel Drop channel_monitor_claim_key from ChannelKeys
This greatly simplifies clients of PeerHandler, and because almost all response messages have already been moved to process_events this doesn't change much effeciency-wise.
TheBlueMatt
force-pushed
the
2018-10-msg-resp-overhaul
branch
from
470d9cc to
294ad32
Compare
This fixes a rather glaring set of race conditions where we generate messages for a given channel in-order but then send them out-of-order due to the two independant message paths we have (events + direct returns). Sadly we give up a bit of effeciency here by handling all messages out-of-band and pushing them into a vec first. That said, the last commit gets to completely remove reentrancy from PeerHandler::read_event, which is super, super nice for client complexity in implementing PeerHandler, so overall I'm quite happy with it.
Based on #213 cause I dont want to rebase it but sadly the fact that a ton of tests had to have a bunch of diff (though should all still be pretty clearly identical in behavior) is gonna cause some pain for other PRs. I'm willing to wait a bit to hit merge for that reason and am happy to rebase as a few other things land, but would ideally like to get this in for 0.0.6 which should be middle/end of this week.