-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Make failure reasons to be flags. #274
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
Conversation
*/ | ||
virtual FailureReason failureReason() const PURE; | ||
virtual uint64_t failureReason() const PURE; |
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 name doesn't make sense anymore. I would do the following:
- Rename FailureReason -> ResponseFlag
- void setResponseFlag(ResponseFlag flag);
- bool getResponseFlag(ResponseFlag flag);
This way it is clear what you are adding flags together and can test if a flag is set. In the future we could add a clearResponseFlag() method if we need 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 assume that if we change FailureReason -> ResponseFlag we'll also need to change access log formatting to allow specifying %RESPONSE_FLAG% instead of %FAILURE_REASON% which will not be backward compatible. Any concerns around this at this point? (If not then I'll go for ReponseFlag).
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.
Yeah I guess so, which makes it a larger change, but I would probably do the right thing here. I'm open to other name ideas also.
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.
For the access log I would do %RESPONSE_FLAGS% (plural) if that is the name.
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.
Well, that's not too much work anyway, main concern around not to be backward compatible. This is def no problem for us, for others it's a simple config change as well, prob not too much to worry about.
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 think it's probably OK right now. I don't think there are too many people using yet and probably even fewer specifying a custom access log config.
@mattklein123 addressed comments. |
@@ -43,10 +45,9 @@ class RequestInfo { | |||
virtual ~RequestInfo() {} | |||
|
|||
/** | |||
* filter can trigger this callback on failed response to provide more details about | |||
* failure. | |||
* filter can set response flags. |
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.
grammar/better comment
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.
fixed in the next iteration
@@ -89,9 +90,11 @@ class RequestInfo { | |||
virtual std::chrono::milliseconds duration() const PURE; | |||
|
|||
/** | |||
* @return the failure reason for richer log experience. | |||
* @return response flags to enrich access log with details around response code. Response flag |
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.
grammar/better comment
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.
fixed in the next iteration
*/ | ||
virtual FailureReason failureReason() const PURE; | ||
virtual bool isSetResponseFlag(ResponseFlag response_flag) const PURE; |
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.
getResponseFlag() or isResponseFlagSet()
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.
here i was following convention used in thrift for optional fields, getResponseFlag() should be ok as well.
} | ||
|
||
const std::string FilterReasonUtils::toShortString(const RequestInfo& request_info) { | ||
std::string result = ""; |
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.
std::string result;
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.
fixed
@@ -17,39 +17,73 @@ const std::string FilterReasonUtils::UPSTREAM_CONNECTION_TERMINATION = "UC"; | |||
const std::string FilterReasonUtils::UPSTREAM_OVERFLOW = "UO"; | |||
const std::string FilterReasonUtils::NO_ROUTE_FOUND = "NR"; | |||
const std::string FilterReasonUtils::FAULT_INJECTED = "FI"; | |||
const std::string FilterReasonUtils::DELAY_INJECTED = "DI"; |
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.
Delete until this is actually used in the code, or use it in the code, and also add to docs.
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 keep this, because the subsequent PR (from me) is be using it? Or would you like to introduce this as another PR?
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.
We could either have all of the changes in one PR (that's harder to review, too many changes)
or have one change for refactoring (this change, and remove DI) and one change with fully DI support.
I'd like to have two clean changes. Let me know if any concerns.
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.
And then a third one that uses all the two codes. I am fine with that as well.
// No failure. | ||
None, | ||
None = 0x0, |
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.
Delete. None is implied by no flags.
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 way caller can check if no flags are set otherwise we'd need to have separate method isAnyResponseFlagSet or something along these lines.
Open to remove None if there are better ways of handling situation above.
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.
Where do you actually need to check if None is set. That location is probably now a bug in the face of something like DI.
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'll check this
.WillByDefault(Return(true)); | ||
ON_CALL(request_info, isSetResponseFlag(ResponseFlag::FaultInjected)) | ||
.WillByDefault(Return(true)); | ||
EXPECT_EQ("UT,FI,DI", FilterReasonUtils::toShortString(request_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.
Nit. FI and UT cannot occur together. Whenever a request is aborted (with HTTP codes or connection termination), it does not go through the rest of the processing pipeline.
The only combination of FI and DI that will make sense in a single request is DI,FI (in order). [Delays followed by aborting a 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.
this was mostly to test basic functionality for multiple flags, i can place comment that it's not real use case but to test functionality
Conflicts: source/common/router/router.cc test/common/router/router_test.cc
…gs_for_access_log
@@ -43,10 +41,9 @@ class RequestInfo { | |||
virtual ~RequestInfo() {} | |||
|
|||
/** | |||
* filter can trigger this callback on failed response to provide more details about | |||
* failure. | |||
* each filter can set independent response flag, flags are accumulated. |
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.
nit: Start with capital letter
} | ||
|
||
// Compiler enforces switch above to cover all the cases and it's impossible to be here, | ||
// but compiler complains on missing return statement, this is to make compiler happy. | ||
NOT_IMPLEMENTED; | ||
} | ||
|
||
bool ConnectionManagerUtility::isTraceableFailure( |
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'm concerned this might get out of date. Should we put in ResponseFlagUtils? I could go either way.
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.
between ConnectionManagerUtility and ResponseFlagUtils i think second one is preferable, will move.
Http::AccessLog::FailureReason failureReason() const override { return failure_reason_; } | ||
void onFailedResponse(FailureReason failure_reason) override { failure_reason_ = failure_reason; } | ||
bool getResponseFlag(ResponseFlag response_flag) const override { | ||
return response_flags_ == response_flag; |
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.
&
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 do that, just kept simple it here, same with set functionality.
Signed-off-by: John Plevyak <jplevyak@gmail.com>
update opencensus
update minimal go version to 1.21
No description provided.