Skip to content
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

fix: handle server-sent termination in RPC #432

Merged
merged 1 commit into from
Oct 23, 2023
Merged

Conversation

MikeDombo
Copy link
Contributor

@MikeDombo MikeDombo commented Oct 22, 2023

Issue #, if available:

Description of changes:
Eventstream server can send a response with the terminate stream flag set, if this flag is set then the client must not send any more messages to that stream. This is sometimes failing on Windows specifically when the client tries to close the operation after the server has already closed it, which results in a protocol error and the client getting disconnected. This change will set the internal state of the operation to be "ended" which means that when the operation is later closed, it will not send the client-side termination message which would result in the protocol error.

Verifying by running our internal test suite on Windows which originally had this issue in a loop. Passed 10 times in a row using this change. Also ran on linux the same tests 5 times which also passed.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@@ -837,6 +844,11 @@ export class RequestResponseOperation<RequestType, ResponseType> extends EventEm
await this.operation.activate(requestMessage);

let message : eventstream.Message = await responsePromise;

// If the server terminated the stream, then set the operation to be ended immediately
if ((message.flags ?? 0) & eventstream.MessageFlags.TerminateStream) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to deserializeResponse (line 852) prior to checking message.flags ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm. It looks like we're good. Was thrown off by the different ordering here vs. what's going on below on 941

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the message flags are already available before deserialization. Deserialization is only for the application-level data. I can switch the order if you think that's better though.

@sbSteveK sbSteveK merged commit 54b50ab into main Oct 23, 2023
10 checks passed
@sbSteveK sbSteveK deleted the fix-rpc-server-term branch October 23, 2023 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants