Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upfix: dont open a feed for a replication stream that has been destroyed #10
Conversation
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
|
wow nice catch! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
|
Thanks! merging and publishing |
pfrazee
merged commit 72639d2
into
master
Dec 30, 2016
pfrazee
deleted the
premature-close-fix
branch
Dec 30, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
|
Published 3.2.3 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
pfrazee commentedDec 29, 2016
Related to dat-land/hypercloud#16
This one was a tricky one!
There was a case where a feed's storage was being closed prematurely. This led to writes failing. Replication would then stall (see mafintosh/hypercore#54) but did appear to complete successfully if the connection was re-established.
Why was the FD closing prematurely? It's possible that the protocol handshake will uncover an extraneous connection, which needs to be destroyed. Sometimes one of those destroyed connections would be the first to enter the open() logic in this repo. The cleanup() check would see that the stream is destroyed, and that there are no other active streams, and so would call feed.close(). Afterward, other non-destroyed streams would continue processing, and try to write into the feed causing the failure.
It looks like there's no harm in just ignoring open() for any stream that's already destroyed, so that's what this PR does.