-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
grpc: Allow to set parent context to a client to propagate stream info #13356
Conversation
This patch allows to set parent context to an async client instance. Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
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.
@dio makes sense to me!
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
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.
Looks good, main question is on whether header parser can be simplified..
/wait
@@ -287,5 +294,26 @@ void HeaderParser::evaluateHeaders(Http::HeaderMap& headers, | |||
} | |||
} | |||
|
|||
void HeaderParser::evaluateHeaders(Http::HeaderMap& headers, | |||
const StreamInfo::StreamInfo* stream_info) const { |
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.
Could we use a null StreamInfo rather than duplicate the add/remove logic?
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.
Sorry, do you mean to have something like NullStreamInfoImpl
?
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.
The only problem with that probably if we have an input that creates StreamInfoHeaderFormatter
(or CompoundHeaderFormatter
) we need to always act as PlainHeaderFormatter
.
For example: given the following HeaderValue
:
- name: key
value: %DOWNSTREAM_LOCAL_ADDRESS%
This creates StreamInfoHeaderFormatter
, if we have NullStreamInfoImpl
we need to provide a default value for stream_info.downstreamLocalAddress()
, which probably could be misleading?
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.
OK, fair enough, but could we merge the control flow so that we have only one internal evaluateHeadersInt and this can branch at the leaves on what to do?
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.
Have done a bit of refactoring, hope it aligns with your expectation :).
@@ -94,6 +101,36 @@ TEST_F(EnvoyGoogleAsyncClientImplTest, StreamHttpStartFail) { | |||
EXPECT_TRUE(grpc_stream == nullptr); | |||
} | |||
|
|||
TEST_F(EnvoyGoogleAsyncClientImplTest, MetadataIsInitialized) { |
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.
Same comment as above here.
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.
@@ -57,6 +57,8 @@ void GrpcClientImpl::check(RequestCallbacks& callbacks, Event::Dispatcher& dispa | |||
} | |||
} | |||
|
|||
options.setParentContext(Http::AsyncClient::ParentContext{&stream_info}); |
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 might be good one day to be able to have async clients automatically detect this information, maybe by introducing a StreamAsyncClient that can pick up on this context. In any case, I think what you have is fine for now.
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
Signed-off-by: Dhi Aurrahman <[email protected]>
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.
LGTM, thanks!
Commit Message: This patch allows to set parent context which carries the current request stream info to a gRPC async client instance.
Risk Level: Low
Testing: Added
Docs Changes: Updated
Release Notes: Added
Fixes #13345