-
Notifications
You must be signed in to change notification settings - Fork 84
Handle server disconnection #263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -74,7 +74,7 @@ size_t trilogy_packet_parser_execute(trilogy_packet_parser_t *parser, const uint | |
| break; | ||
| } | ||
| case S_SEQ: { | ||
| if (cur_byte != parser->sequence_number) { | ||
| if (cur_byte != parser->sequence_number && cur_byte > 0) { | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Some vague concerns that this could mask some legitimate error case, but I couldn't think of any such cases so maybe it's fine.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, it felt a bit bad writtting this, but I have no better idea. |
||
| *error = TRILOGY_INVALID_SEQUENCE_ID; | ||
| return i; | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@composerinteralia if the server is sending back a
4031here should Trilogy know the connection is closed and then return aConnectionClosederror instead of anEOFError?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally yes, in practice it's way trickier to implement than it sounds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been trying to find any
mysqldocumentation that details all of the possible out-of-sequence messages and I've come up blank. 😞Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed that it's ideal but probably not so easy to do. It's also a bit awkward that
trilogy_error_recoverable_pwill return true for this case, but we'd find out quickly on the next attempt that the connection is closed, so 🤷🏻.I guess the only worry would be if there are any server-initiated communications that don't also close the connection immediately. That'd leave us in a bad state. But it might not be possible. I'm not too sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this is what I was trying to find documentation for but found nada 🤷
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In libmysqlclient, when it expects a
pkt_nrof1, but it gets0, it marks the socket as unusable and proceeds with parsing, since "The caller should handle the error code in the packet..."https://github.com/mysql/mysql-server/blob/447eb26e094b444a88c532028647e48228c3c04f/sql-common/net_serv.cc#L1518-L1560
The logic is:
if (pkt_nr != (uchar)net->pkt_nr)1:if (net->pkt_nr == 1)net->error = NET_ERROR_SOCKET_UNUSABLE;net->last_errno = ER_NET_PACKETS_OUT_OF_ORDER;1:net->pkt_nr = pkt_nr + 1;return falseSo, I'm thinking we can do the same. We can assume the socket is closed in this specific case (expecting
1, got0) and continue parsing/handling the error message. I think it's possible there are other0-sequence out-of-order interruptions from the server, but this is the only "documented" case I could find.