Not returning on connection close for chainsync, block-fetch and tx-submission protocol #1141
Conversation
Signed-off-by: Jenita <[email protected]>
Signed-off-by: Jenita <[email protected]>
Signed-off-by: Jenita <[email protected]>
Closes #1112 |
Signed-off-by: Jenita <[email protected]>
Signed-off-by: Jenita <[email protected]>
Signed-off-by: Jenita <[email protected]>
Signed-off-by: Jenita <[email protected]>
Signed-off-by: Jenita <[email protected]>
| // Stop the protocol explicitly | ||
| if err := chainSyncProtocol.Client.Stop(); err != nil { | ||
| t.Fatalf("failed to stop chain sync: %s", err) | ||
| } |
There was a problem hiding this comment.
This isn't really a good way to test this. The protocols aren't meant to be arbitrarily started/stopped from the outside, only from within the actual protocol. Instead, you should use the mock connection to send the Done message to shut it down.
| } | ||
|
|
||
| return false | ||
| } |
There was a problem hiding this comment.
I'm not sure that any of this is necessary. The docs for io.ReadFull() and binary.Read() both say that they'll only return io.EOF or io.ErrUnexpectedEOF. We may want to add a check for io.ErrUnexpectedEOF and remap it to io.EOF in the muxer (links below), and then we only need to check for errors.Is(err, io.EOF) anywhere below.
Lines 304 to 306 in a57c097
Lines 331 to 333 in a57c097
| } | ||
|
|
||
| return true | ||
| } |
There was a problem hiding this comment.
Thinking further about this, we only need to care about the .Server side of each protocol. If we're acting as a client and the connection is unexpectedly closed (we didn't call .Close() ourselves), it should be an error condition.
2 participants
Closes #1112