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

Handle RST_STREAM/NO_ERROR #78

Merged
merged 2 commits into from May 16, 2023

Conversation

edsko
Copy link
Contributor

@edsko edsko commented May 12, 2023

This closes #76 .

@kazu-yamamoto , this is two commits.

  1. In the first commit, I don't change any code at all, but I add a diagram in which I document the various stream state transitions and how they are implemented. I wanted to make sure that I understood these very well before adding a new transition (the one for RST_STREAM). The diagram I add in this commit does not yet reflect the change I want to make, but rather the status quo prior to this PR.
  2. In the second commit I then make the actual change, which was now actually quite simple; there were a few ways to do it, but for consistency I now return the Closed stream state, which is then applied in processState; this matches what you do for all the other cases.

As I was working on my own library, I noticed that there is a second important use case for this fix (the first being the one I outline in #76): it's not just important when the server wants to tell the client "don't send any more here, we're done", but also when the server wants to tell the client "this particular method is not actually supported at all, don't even start sending me anything". Not terribly relevant for you, except to let you know that I've tested both scenarios with the fix from this PR, and they are now both working correctly.

Related bug?

However, something that had me concerned as I was documenting the state transitions: except in the case of RST_STREAM, a stream is never really closed on the client side (as I mention below the diagram in the code, when the streamState IORef is collected, it is typically in HalfClosedRemote state). This doesn't matter by itself, but I started tracking when these are then GCed, and it appears that they are not GCed at all, until the entire connection to the server is closed.

What I would have expected to see when I started documenting all the state transitions is that when the client sends their final message (meaning, the thread that gets spawned by requestStreaming terminates), the connection transitions to HalfClosedLocal, at which point it can be closed entirely and forgotten about once the server closes their end too. What do you think? Should I try to submit a PR for that, also, or have I misunderstood what the intended control flow?

(I can open a separate issue about this if that's better.)

@kazu-yamamoto kazu-yamamoto self-requested a review May 16, 2023 03:36
Copy link
Owner

@kazu-yamamoto kazu-yamamoto left a comment

Choose a reason for hiding this comment

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

Excellent!

@kazu-yamamoto kazu-yamamoto merged commit 059b244 into kazu-yamamoto:master May 16, 2023
15 checks passed
@kazu-yamamoto
Copy link
Owner

Merged.
Thank you for your contribution!

If a stream is not GCed, it's a bug.
Please send another PR!

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.

RST_STREAM with NO_ERROR should not throw StreamErrorIsReceived
2 participants