-
Notifications
You must be signed in to change notification settings - Fork 5.4k
add response code details to stream info #6530
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
Changes from 2 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 |
|---|---|---|
|
|
@@ -14,6 +14,7 @@ | |
|
|
||
| #include "common/common/assert.h" | ||
| #include "common/protobuf/protobuf.h" | ||
| #include "common/singleton/const_singleton.h" | ||
|
|
||
| #include "absl/types/optional.h" | ||
|
|
||
|
|
@@ -64,6 +65,20 @@ enum ResponseFlag { | |
| LastFlag = StreamIdleTimeout | ||
| }; | ||
|
|
||
| /** | ||
| * Constants for the response code details field of StreamInfo. | ||
| * | ||
| * These provide details about the stream state such as whether the | ||
| * response is from the upstream or from envoy (in case of a local reply). | ||
| * Custom extensions can define additional values provided they are appropriately | ||
| * scoped to avoid collisions. | ||
| */ | ||
| struct ResponseCodeDetailValues { | ||
| const std::string RC_SET_BY_UPSTREAM = "response_code_set_by_upstream"; | ||
|
Member
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. nit: I wonder if we have to prefix RC here given the structs name?
Contributor
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. Removed the RC_ prefix |
||
| }; | ||
|
|
||
| typedef ConstSingleton<ResponseCodeDetailValues> ResponseCodeDetails; | ||
|
|
||
| struct UpstreamTiming { | ||
| /** | ||
| * Sets the time when the first byte of the request was sent upstream. | ||
|
|
@@ -116,6 +131,12 @@ class StreamInfo { | |
| */ | ||
| virtual void setResponseFlag(ResponseFlag response_flag) PURE; | ||
|
|
||
| /** | ||
| * @param rc_details the response code details string to set for this request. | ||
|
Contributor
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. Maybe some details here about what response code details are?
Contributor
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. Done |
||
| * See ResponseCodeDetailValues above for well-known constants. | ||
| */ | ||
| virtual void setResponseCodeDetails(absl::string_view rc_details) PURE; | ||
|
|
||
| /** | ||
| * @param response_flags the response_flags to intersect with. | ||
| * @return true if the intersection of the response_flags argument and the currently set response | ||
|
|
@@ -153,6 +174,11 @@ class StreamInfo { | |
| */ | ||
| virtual absl::optional<uint32_t> responseCode() const PURE; | ||
|
|
||
| /** | ||
| * @return the response code details. | ||
| */ | ||
| virtual const absl::optional<std::string>& responseCodeDetails() const PURE; | ||
|
|
||
| /** | ||
| * @return the time that the first byte of the request was received. | ||
| */ | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -792,6 +792,8 @@ void Filter::onUpstreamHeaders(uint64_t response_code, Http::HeaderMapPtr&& head | |
| onUpstreamComplete(); | ||
| } | ||
|
|
||
| callbacks_->streamInfo().setResponseCodeDetails( | ||
| StreamInfo::ResponseCodeDetails::get().RC_SET_BY_UPSTREAM); | ||
|
Contributor
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. I think this PR would be a bit more correct if you also did the work to set the string to nothing in sendLocalReply. I don't think we have any response filters that pause on encodeHeaders, but if we did it could be the case that while that encoder filter were doing its RPC, it took too long and for example triggered an idle timeout where the HCM would sendLocalReply. Because that could transform, say, a 200 from upstream to a 408 where the details would eventually be "stream timeout" but for today would be "" rather than "response_code_set_by_upstream"
Contributor
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. Done |
||
| callbacks_->encodeHeaders(std::move(headers), end_stream); | ||
| } | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -100,6 +100,14 @@ struct StreamInfoImpl : public StreamInfo { | |
|
|
||
| absl::optional<uint32_t> responseCode() const override { return response_code_; } | ||
|
|
||
| const absl::optional<std::string>& responseCodeDetails() const override { | ||
| return response_code_details_; | ||
| } | ||
|
|
||
| void setResponseCodeDetails(absl::string_view rc_details) override { | ||
|
Member
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. Is it up to the caller on how to enrich this information? Or do you imagine codifying this somehow, i.e a comma delimited list of details?
Contributor
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. My thinking was that this will be just one of the string constants defined in ResponseCodeDetailValues. That currently only has 1 value but that will change soon (#6542). Also, since this is a string, 3rd party extensions can add additional values if it doesn't make sense to add it to OSS envoy. I don't see a need for making this an array (or comma-separated list). @alyssawilk wdyt?
Contributor
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. Just to add another point - I think the idea is that there should be enough distinct strings available to uniquely specify why envoy is returning an error code (more or less one for each time sendLocalReply is called). So a list of strings should not be necessary.
Contributor
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. I'm fine with it as-is. For single-hop responses we only need one rc-details. It might be useful to have a full trace of what happened somewhere (500-retried, timeout-retries, gave up and sent 500) but I think that's better off via some other trace mechanism where we can put arbitrary information about how much time was spent in each filter etc. etc. For multi-hop responses while we might want both layers captured in access logs (e.g. layer-2 envoy had timeout, layer-1 envoy proxied response code sent by upstream) I think that the information from prior hops would be transmitted via headers, and could be sent to access logs via logging the proxy-status header. SG?
Member
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. Sounds good, thanks! |
||
| response_code_details_.emplace(rc_details); | ||
| } | ||
|
|
||
| void addBytesSent(uint64_t bytes_sent) override { bytes_sent_ += bytes_sent; } | ||
|
|
||
| uint64_t bytesSent() const override { return bytes_sent_; } | ||
|
|
@@ -205,6 +213,7 @@ struct StreamInfoImpl : public StreamInfo { | |
|
|
||
| absl::optional<Http::Protocol> protocol_; | ||
| absl::optional<uint32_t> response_code_; | ||
| absl::optional<std::string> response_code_details_; | ||
| uint64_t response_flags_{}; | ||
| Upstream::HostDescriptionConstSharedPtr upstream_host_{}; | ||
| bool health_check_request_{}; | ||
|
|
||
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.
One other minor nit - do you think it's worth clarifying what's done now vs what this will do?
These will provide such details, but right now they only do rc_set_by_upstream
I'd be fine with a tracking issue assigned my way for actually setting values in sendLocalReply and referencing the issue 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.
Filed #6542 to track this. I'll add a reference to this in the code.