Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Allow multiplexed upstream servers to half close the stream before the downstream #34461
Allow multiplexed upstream servers to half close the stream before the downstream #34461
Changes from 9 commits
7263c53
fd17760
723ed65
1d8172c
3ba7cc4
6133efc
fcf2a76
f24bc34
0e881dc
b7b746f
af60f0b
01ae68b
1f269a4
1b961df
8ae88a0
d8aabba
2166fcb
e2deca2
9e9428f
71ce1f0
68c807e
9c308ba
2d8cb15
e1c00d0
018a3e4
9a692f3
bd30f81
b9948ab
e224738
e4ae6b4
d5320da
b804cb5
4b305d9
9155e49
49b6162
c02ac47
d965ff6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
do we have half close behavior commented anywhere? comment link to it?
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 have added docs and more comments.
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.
how is this different from remote_decode_complete? it's set when we see end stream. I think it's just badly named.
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.
can we explicitly comment how this differs from local_complete as well?
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.
It is a bit messy. I have added more comments to
local_complete
andencoder_end_stream
and left a TODO to always useencoder_end_stream
for tracking end_stream state in encoder filer iteration.I will do this refactor when the runtime flag is removed.
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.
right now it's only called if half close is enabled right? should it be an envoy bug if we early return?
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.
Added ASSERT
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 have concerns about having this as a follow-up. I believe you have good intent but I also have seen the number of times you've been yanked away from projects due to internal reprioritization and this code is complicated enough I'm pretty strongly averse to making it harder to understand and having a TODO to clean up :-/
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.
Explicitly calling this out as a blocking issue.
Given the level of unresolved tech debt* I am not ok with plan "sort it out when we remove the flag"
*https://github.com/envoyproxy/envoy/issues?q=is%3Aopen+label%3A%22tech+debt%22+assignee%3Ayanavlasov+
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 don't want to nitpick but is this about request completion?
looks like ignoring half close, local_complete_ is set from setLocalComplete which is set from ConnectionManagerImpl::doEndStream which is called on [stream reset or ] HCM endStream which is called from filter manager maybeEndEncode.
Isn't it really a way to say the encode has started which is used (in the non-half-close case) to neuter the complete-or-not decode side of things?
it feels like prior to any half close logic, writes to this boolean are "have we started encoding" and reads are "do we want to stop decoding" and if we replaced read calls with shouldDecode() {finished_encoding_ && !half_close} we could avoid the extra boolean
thoughts?
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.
why not just use a helper function which checks both booleans?
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.
this is what local complete was used for previously. And it appears to me in most of the decode calls we abort if local complete and not based on should_stop_decoding which makes me think this is not doing what it says it's doing. I think we're adding complexity and not correctness here,