Skip to content
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

Add option to only return simple exception messages #10117

Closed
wants to merge 1 commit into from

Conversation

jaymode
Copy link
Member

@jaymode jaymode commented Mar 17, 2015

Adds a setting to disable detailed error messages and full exception stack traces
in http responses. When set to false, the error_trace request parameter will be
ignored and only the message of the first ElasticsearchException will be output;
no nested exception messages will be output.

@jaymode
Copy link
Member Author

jaymode commented Mar 17, 2015

@s1monw can you review this?

while (t != null) {
if (counter++ > 10) {
break;
Copy link
Member

Choose a reason for hiding this comment

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

Won't this cause no exception to be added at all? Shouldn't we be returning something in this case still?

@@ -72,6 +72,10 @@ be cached for. Defaults to `1728000` (20 days)
header should be returned. Note: This header is only returned, when the setting is
set to `true`. Defaults to `false`

|`http.emit_stack_trace` |Enables or disables the output of stack traces in response
output. Note: When set to `false` this setting overrides the `error_trace` request parameter
and no stack trace will be output; only a simple message will be displayed. Defaults to `true`
Copy link
Contributor

Choose a reason for hiding this comment

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

wait this defaults to true? I don't think we should do this it should be default to false!

Copy link
Member

Choose a reason for hiding this comment

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

If we do that then we need to make sure the tests will always override this to true.

Copy link
Contributor

Choose a reason for hiding this comment

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

oh I think I misread it by default we print the stacktraces right? ok then true is just fine :)

@jaymode
Copy link
Member Author

jaymode commented Mar 18, 2015

@rjernst pushed a commit addressing the feedback

}

if (!added) {
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps this function would be easier if it were structured like detailedMessage(t)? Then this function can just return when it finds an ES exc, and exhausting the loop can have a single return statement at the end. I think the null case should be extracted out since it is the same whether we do simple or detailed exceptions? The caller locations in convert will look more inline then, like:

if (t == null) {
    buidler.field("error", "Unknown");
} else if (channel.emitStackTrace()) {
    builder.field("error", detailedMessage(t));
} else {
    builder.field("error", simpleMessage(t));
}

@jaymode
Copy link
Member Author

jaymode commented Mar 18, 2015

@rjernst pushed some commits based on the additional feedback. I also changed the setting name; I think the original name was confusing and didn't accurately represent all of the behavior being changed.

return builder;
}

private static void buildErrorTrace(RestChannel channel, Throwable t, XContentBuilder builder) throws IOException {
Copy link
Member

Choose a reason for hiding this comment

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

maybe move the conditional logic back out to the caller? the null check isn't needed, and the function name implies it always adds this trace, when in fact it depends on the request.

@rjernst
Copy link
Member

rjernst commented Mar 18, 2015

Looks good, just a couple more comments, no need for further review.

Adds a setting to disable detailed error messages and full exception stack traces
in HTTP responses. When set to false, the error_trace request parameter will result
in a HTTP 400 response. When the error_trace parameter is not present, the message
of the first ElasticsearchException will be output and no nested exception messages
will be output.
@jaymode
Copy link
Member Author

jaymode commented Mar 18, 2015

Committed in 105bdd4 and backported. Thanks @rjernst

@dadoonet
Copy link
Member

@jaymode Note that this commit breaks transport plugins.
I'll fix that. What should be the default value for RestChannel#detailedErrorsEnabled in transport plugins?

@rjernst
Copy link
Member

rjernst commented Mar 28, 2015

I think the default should always be true. This should only be disabled in rare circumstances (e.g. security concerns).

@jaymode
Copy link
Member Author

jaymode commented Mar 28, 2015

@dadoonet thanks for fixing it. @rjernst is right, the default should always be true

dadoonet added a commit to elastic/elasticsearch-transport-thrift that referenced this pull request Mar 28, 2015
RestChannel has changed with this PR: elastic/elasticsearch#10117

Closes #47.
(cherry picked from commit 2747a45)
dadoonet added a commit to elastic/elasticsearch-transport-thrift that referenced this pull request Mar 28, 2015
RestChannel has changed with this PR: elastic/elasticsearch#10117

Closes #47.
(cherry picked from commit 2747a45)
(cherry picked from commit bc8abd7)
dadoonet added a commit to elastic/elasticsearch-transport-thrift that referenced this pull request Mar 28, 2015
RestChannel has changed with this PR: elastic/elasticsearch#10117

Closes #47.
dadoonet added a commit to elastic/elasticsearch-transport-memcached that referenced this pull request Mar 29, 2015
RestChannel has changed with this PR: elastic/elasticsearch#10117

Closes #38.
(cherry picked from commit 5d8ec9b)
dadoonet added a commit to elastic/elasticsearch-transport-memcached that referenced this pull request Mar 29, 2015
RestChannel has changed with this PR: elastic/elasticsearch#10117

Closes #38.
(cherry picked from commit 5d8ec9b)
(cherry picked from commit 6873b43)
dadoonet added a commit to elastic/elasticsearch-transport-memcached that referenced this pull request Mar 29, 2015
RestChannel has changed with this PR: elastic/elasticsearch#10117

Closes #38.
dadoonet pushed a commit to elastic/elasticsearch-transport-wares that referenced this pull request Mar 29, 2015
`RestChannel` now has a parameter `detailedErrorsEnabled` which wasn't being passed in, causing a `NoSuchMethodError` if you try to run it with elasticsearch 1.5 (and a compile error if you tried to compile it).

See also elastic/elasticsearch#10117

Closes #30.
dadoonet pushed a commit to elastic/elasticsearch-transport-wares that referenced this pull request Mar 29, 2015
`RestChannel` now has a parameter `detailedErrorsEnabled` which wasn't being passed in, causing a `NoSuchMethodError` if you try to run it with elasticsearch 1.5 (and a compile error if you tried to compile it).

See also elastic/elasticsearch#10117

Closes #30.
(cherry picked from commit 91445ef)
dadoonet pushed a commit to elastic/elasticsearch-transport-wares that referenced this pull request Mar 29, 2015
`RestChannel` now has a parameter `detailedErrorsEnabled` which wasn't being passed in, causing a `NoSuchMethodError` if you try to run it with elasticsearch 1.5 (and a compile error if you tried to compile it).

See also elastic/elasticsearch#10117

Closes #30.
(cherry picked from commit 91445ef)
(cherry picked from commit 849a457)
@clintongormley clintongormley changed the title [HTTP] add option to only return simple exception messages Add option to only return simple exception messages Jun 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants