HLRC: Fix strict setting exception handling #37247

hub-cap · 2019-01-09T02:07:51Z

The LLRC's exception handling for strict mode was previously throwing an
exception the HLRC assumed was an error response. This is not the case
if the result is valid in strict mode, as it will return the proper
response wrapped in an exception with warnings. This commit fixes the
HLRC such that it no longer spews if it encounters a strict LLRC
response.

Closes #37090

The LLRC's exception handling for strict mode was previously throwing an exception the HLRC assumed was an error response. This is not the case if the result is valid in strict mode, as it will return the proper response wrapped in an exception with warnings. This commit fixes the HLRC such that it no longer spews if it encounters a strict LLRC response. Closes elastic#37090

elasticmachine · 2019-01-09T02:07:53Z

Pinging @elastic/es-core-features

hub-cap · 2019-01-09T14:51:09Z

@elasticmachine please run gradle build tests 1

javanna · 2019-01-10T15:11:33Z

client/rest-high-level/src/main/java/org/elasticsearch/client/RestHighLevelClient.java

+
+        if (responseException instanceof WarningFailureException) {
+            elasticsearchException = new ElasticsearchStatusException("Warnings/Deprecations caused response to fail", restStatus,
+                responseException);


I find using ElasticsearchStatusException almost as weird as using ResponseException. That is because such exceptions are meant for error status codes, while warnings can come back with any response.

I would prefer if we could have a separate catch for the warnings case, with a different exception that does not extend ResponseException. Maybe we could add a new exception to the low-level client that does not extend ResponseException, and let the high-level client bubble it up as-is? Not sure what I may be missing that prevents us from going down this route...

I think all we have to do for that is to make the new exception not extend ResponseException. It might have to extend RuntimeException so we don't break compilation. Which'd be fine with me.

you are right Nik, probably we do not even need a catch for the new exception, just let it bubble up.

The only reason I used the existing ElasticsearchStatusException was because that is what was thrown before. If you take a look at https://github.com/elastic/elasticsearch/blob/master/client/rest-high-level/src/main/java/org/elasticsearch/client/RestHighLevelClient.java#L1670, it is the method that sync/async both call when a ResponseException is thrown from the LLRC. Im not sure there is a ton of value wrapping either of these in ElasticsearchStatusException. I think removing this would be a breaking change tho?

and to @nik9000 point, if we just throw another exception, it works great for sync, but for async it throws the following

UncategorizedExecutionException[Failed execution ]; nested: ExecutionException[org.elasticsearch.client.DeprecationException

That said, ofc we can make it do whatever we want. Id still lean toward 1) doing nothing different and still throwing a ElasticsearchStatusException, or 2) unwrapping both the ResponseException and WarningFailureException and throwing them w/o the ElasticsearchStatusException (breaking?)

I think that removing the ElasticsearchStatusException wrapped from the ResponseException thrown would be a bad breaking change.

I think that one has been around much longer, yeah. But i'm just going from memory. We could throw a special deprecation exception instead, right?

yea this is what the code does as is, even with it being child of ResponseException, its just currently wrapped in a ElasticsearchStatusException as well.

@javanna Id like your opinion on whether to break the current functionality, which is to always return an ElasticsearchStatusException unless its a random exception we dont know about. Ill gladly throw the WarningFailureException w/o wrapping it, just want to make sure thats the correct thing to do WRT compatibility. I think @nik9000 says he is ok with it, correct @nik9000 ?

I'm fine throwing the WarningFailureException, unwrapped, not extending ElasticsearchStatusException.

I am fine too with rethrowing WarningFailureException as-is.

hub-cap · 2019-01-23T18:13:20Z

@javanna @nik9000 Now we have a nice throw (see below) from the async code, with one caveat. The async code uses this from server which expects any exception to be either an ElasticsearchException or a RuntimeException. I decided to make WarningFailureException extend RuntimeException so it would not wrap it here.

org.elasticsearch.client.WarningFailureException: method [PUT], host [http://127.0.0.1:9200], URI [/index/type/id?timeout=1m], status line [HTTP/1.1 201 Created]
Warnings: [[types removal] Specifying types in document index requests is deprecated, use the typeless endpoints instead (/{index}/_doc/{id}, /{index}/_doc, or /{index}/_create/{id}).]
---
_index: "index"
_type: "type"
_id: "id"
_version: 1
result: "created"
_shards:
  total: 2
  successful: 1
  failed: 0
_seq_no: 0
_primary_term: 1

Id love another quick look.

hub-cap · 2019-01-23T18:59:01Z

@elasticmachine run elasticsearch-ci/1

javanna

LGTM

javanna · 2019-01-25T15:55:30Z

client/rest/src/main/java/org/elasticsearch/client/ResponseException.java

@@ -30,7 +30,7 @@
 * Exception thrown when an elasticsearch node responds to a request with a status code that indicates an error.
 * Holds the response that was returned.
 */
-public final class ResponseException extends IOException {
+public class ResponseException extends IOException {


I think that these changes to ResponseException are no longer needed?

doh, good call!

javanna · 2019-01-25T15:55:51Z

client/rest/src/main/java/org/elasticsearch/client/WarningFailureException.java

+// if the exception is not of type ElasticsearchException or RuntimeException it will be wrapped in a UncategorizedExecutionException
+public class WarningFailureException extends RuntimeException {
+
+    private Response response;


make it final?

* master: Expose retention leases in shard stats (elastic#37991) Make primary terms fields private in index shard (elastic#38036) ML: Add reason field in JobTaskState (elastic#38029) Log flush_stats and commit_stats in testMaybeFlush HLRC: Fix strict setting exception handling (elastic#37247) Test: Enable strict deprecation on all tests (elastic#36558) Removes typed calls from YAML REST tests (elastic#37611) Switch default time format for ingest from Joda to Java for v7 (elastic#37934) Remove deprecated Plugin#onModule extension points (elastic#37866) Geo: Fix Empty Geometry Collection Handling (elastic#37978)

romseygeek · 2019-01-31T11:04:14Z

I think this is causing (non-reproducible) failures in FullClusterRestartIT, specifically here:

elasticsearch/qa/full-cluster-restart/src/test/java/org/elasticsearch/upgrades/FullClusterRestartIT.java

Line 1057 in b889221

} catch (ResponseException e) {

The test is anticipating a ResponseException, but it will now get a WarningFailureException instead and so won't catch it.

The LLRC's exception handling for strict mode was previously throwing an exception the HLRC assumed was an error response. This is not the case if the result is valid in strict mode, as it will return the proper response wrapped in an exception with warnings. This commit fixes the HLRC such that it no longer spews if it encounters a strict LLRC response. Closes elastic#37090 Relates elastic#37247

The LLRC's exception handling for strict mode was previously throwing an exception the HLRC assumed was an error response. This is not the case if the result is valid in strict mode, as it will return the proper response wrapped in an exception with warnings. This commit fixes the HLRC such that it no longer spews if it encounters a strict LLRC response. Closes #37090 Relates #37247

We now throw a WarningFailureException instead of ResponseException if there's any warning in a response. This change leads to the failures of testSnapshotRestore in the BWC builds for the last two days. Relates #37247

hub-cap added >enhancement :Clients/Java Low Level REST Client Minimal dependencies Java Client for Elasticsearch v7.0.0 :Core/Features/Java High Level REST Client v6.7.0 labels Jan 9, 2019

hub-cap requested review from nik9000 and javanna January 9, 2019 02:07

Merge remote-tracking branch 'upstream/master' into hlrc_strict

0b375cf

javanna reviewed Jan 10, 2019

View reviewed changes

hub-cap added 2 commits January 23, 2019 11:04

Merge remote-tracking branch 'upstream/master' into hlrc_strict

0b41895

Just throw the exception itself

e11dbd5

Merge remote-tracking branch 'upstream/master' into hlrc_strict

96796d1

javanna approved these changes Jan 25, 2019

View reviewed changes

hub-cap added 4 commits January 28, 2019 10:25

fixups test + review

64f9e66

Merge remote-tracking branch 'upstream/master' into hlrc_strict

c53dd14

move variable

9ba7b44

Merge remote-tracking branch 'upstream/master' into hlrc_strict

5b5ac9e

hub-cap merged commit 2cbc688 into elastic:master Jan 30, 2019

hub-cap added the backport pending label Jan 30, 2019

hub-cap mentioned this pull request Jan 31, 2019

HLRC: Fix strict setting exception handling #38112

Merged

hub-cap removed the backport pending label Jan 31, 2019

dnhatn mentioned this pull request Feb 2, 2019

Adapt LLRest warning exception in FullClusterRestartIT #38253

Merged

colings86 added v7.0.0-beta1 and removed v7.0.0 labels Feb 7, 2019

danielmitterdorfer removed the :Clients/Java Low Level REST Client Minimal dependencies Java Client for Elasticsearch label Feb 8, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

HLRC: Fix strict setting exception handling #37247

HLRC: Fix strict setting exception handling #37247

hub-cap commented Jan 9, 2019

elasticmachine commented Jan 9, 2019

hub-cap commented Jan 9, 2019

javanna Jan 10, 2019

nik9000 Jan 11, 2019

javanna Jan 11, 2019

hub-cap Jan 14, 2019

hub-cap Jan 14, 2019

nik9000 Jan 14, 2019

hub-cap Jan 14, 2019

hub-cap Jan 16, 2019

nik9000 Jan 16, 2019

javanna Jan 22, 2019

hub-cap commented Jan 23, 2019

hub-cap commented Jan 23, 2019

javanna left a comment

javanna Jan 25, 2019

hub-cap Jan 28, 2019

javanna Jan 25, 2019

romseygeek commented Jan 31, 2019

HLRC: Fix strict setting exception handling #37247

HLRC: Fix strict setting exception handling #37247

Conversation

hub-cap commented Jan 9, 2019

elasticmachine commented Jan 9, 2019

hub-cap commented Jan 9, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hub-cap commented Jan 23, 2019

hub-cap commented Jan 23, 2019

javanna left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

romseygeek commented Jan 31, 2019