Skip to content

Conversation

RomanDzhabarov
Copy link
Member

No description provided.

*/
virtual FailureReason failureReason() const PURE;
virtual uint64_t failureReason() const PURE;
Copy link
Member

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:

  1. Rename FailureReason -> ResponseFlag
  2. void setResponseFlag(ResponseFlag flag);
  3. 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.

Copy link
Member Author

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).

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

@RomanDzhabarov
Copy link
Member Author

@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.
Copy link
Member

Choose a reason for hiding this comment

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

grammar/better comment

Copy link
Member Author

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
Copy link
Member

Choose a reason for hiding this comment

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

grammar/better comment

Copy link
Member Author

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;
Copy link
Member

Choose a reason for hiding this comment

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

getResponseFlag() or isResponseFlagSet()

Copy link
Member Author

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 = "";
Copy link
Member

Choose a reason for hiding this comment

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

std::string result;

Copy link
Member Author

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";
Copy link
Member

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.

Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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,
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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));
Copy link
Member

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].

Copy link
Member Author

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

@@ -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.
Copy link
Member

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(
Copy link
Member

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.

Copy link
Member Author

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;
Copy link
Member

Choose a reason for hiding this comment

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

&

Copy link
Member Author

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.

@RomanDzhabarov RomanDzhabarov merged commit 4332dcf into master Dec 15, 2016
@mattklein123 mattklein123 deleted the flags_for_access_log branch December 17, 2016 20:45
lizan pushed a commit to lizan/envoy that referenced this pull request Nov 25, 2019
Signed-off-by: John Plevyak <jplevyak@gmail.com>
lambdai pushed a commit to lambdai/envoy-dai that referenced this pull request Oct 16, 2020
krinkinmu pushed a commit to krinkinmu/envoy that referenced this pull request Nov 1, 2024
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.

3 participants