Fix Bug in Azure Repo Exception Handling #47968
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We were incorrectly handling `IOExceptions` thrown by the `InputStream` side of the upload operation, resulting in a `ClassCastException` as we expected to never get `IOException` from the Azure SDK code but we do in practice. This PR also sets an assertion on `markSupported` for the streams used by the SDK as adding the test for this scenario revealed that the SDK client would retry uploads for non-mark-supporting streams on `IOException` in the `InputStream`.
original-brownbear
added
>bug
:Distributed Coordination/Snapshot/Restore
Collaborator
|
Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore) |
| assertThat(blocks.isEmpty(), is(true)); | ||
| } | ||
|
|
||
| public void testRetryUntilFail() throws IOException { |
Contributor
Author
There was a problem hiding this comment.
This test is admittedly a little random/weird, but I figured it captured the initial issue that showed this bug to some degree at least.
tlrx
approved these changes
Oct 14, 2019
plugins/repository-azure/src/main/java/org/elasticsearch/repositories/azure/SocketAccess.java
Outdated
Show resolved
Hide resolved
ywelsch
suggested changes
Oct 14, 2019
| if (cause instanceof IOException) { | ||
| throw (IOException) e.getCause(); | ||
| } else { | ||
| throw new IOException(cause); |
Contributor
There was a problem hiding this comment.
It feels wrong to wrap this as an IOException. Can we just use Throwables.rethrow(cause) here?
Contributor
Author
There was a problem hiding this comment.
I'd rather not tbh. We could wrap in a different exception but Throwables.rethrow itself just casts to RunTimeException doesn't it? In the end if the SDK ever changes or we missed some checked exception in our code, we'll get the same bug we started from here again won't we?
Contributor
There was a problem hiding this comment.
but Throwables.rethrow itself just casts to RunTimeException doesn't it
no it does not
Contributor
Author
There was a problem hiding this comment.
Huh, Java works in mysterious ways. Sorry for the noise, my bad seems it works just fine :)
=> used it all the way now.
plugins/repository-azure/src/main/java/org/elasticsearch/repositories/azure/SocketAccess.java
Outdated
Show resolved
Hide resolved
Contributor
Author
|
Jenkins run elasticsearch-ci/2 (random ML thing) |
Contributor
Author
|
Jenkins run elasticsearch-ci/packaging-sample (Vagrant ...) |
Contributor
Author
|
Jenkins run elasticsearch-ci/2 (random ML thing again ) |
Contributor
Author
|
Thank Yannick + Tanguy! I'm wondering, should this go to |
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this pull request
Oct 15, 2019
We were incorrectly handling `IOExceptions` thrown by the `InputStream` side of the upload operation, resulting in a `ClassCastException` as we expected to never get `IOException` from the Azure SDK code but we do in practice. This PR also sets an assertion on `markSupported` for the streams used by the SDK as adding the test for this scenario revealed that the SDK client would retry uploads for non-mark-supporting streams on `IOException` in the `InputStream`.
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this pull request
Oct 15, 2019
We were incorrectly handling `IOExceptions` thrown by the `InputStream` side of the upload operation, resulting in a `ClassCastException` as we expected to never get `IOException` from the Azure SDK code but we do in practice. This PR also sets an assertion on `markSupported` for the streams used by the SDK as adding the test for this scenario revealed that the SDK client would retry uploads for non-mark-supporting streams on `IOException` in the `InputStream`.
Contributor
yes |
original-brownbear
added a commit
that referenced
this pull request
Oct 15, 2019
We were incorrectly handling `IOExceptions` thrown by the `InputStream` side of the upload operation, resulting in a `ClassCastException` as we expected to never get `IOException` from the Azure SDK code but we do in practice. This PR also sets an assertion on `markSupported` for the streams used by the SDK as adding the test for this scenario revealed that the SDK client would retry uploads for non-mark-supporting streams on `IOException` in the `InputStream`.
original-brownbear
added a commit
that referenced
this pull request
Oct 15, 2019
We were incorrectly handling `IOExceptions` thrown by the `InputStream` side of the upload operation, resulting in a `ClassCastException` as we expected to never get `IOException` from the Azure SDK code but we do in practice. This PR also sets an assertion on `markSupported` for the streams used by the SDK as adding the test for this scenario revealed that the SDK client would retry uploads for non-mark-supporting streams on `IOException` in the `InputStream`.
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this pull request
Oct 15, 2019
We were incorrectly handling `IOExceptions` thrown by the `InputStream` side of the upload operation, resulting in a `ClassCastException` as we expected to never get `IOException` from the Azure SDK code but we do in practice. This PR also sets an assertion on `markSupported` for the streams used by the SDK as adding the test for this scenario revealed that the SDK client would retry uploads for non-mark-supporting streams on `IOException` in the `InputStream`.
original-brownbear
added a commit
that referenced
this pull request
Oct 15, 2019
We were incorrectly handling `IOExceptions` thrown by the `InputStream` side of the upload operation, resulting in a `ClassCastException` as we expected to never get `IOException` from the Azure SDK code but we do in practice. This PR also sets an assertion on `markSupported` for the streams used by the SDK as adding the test for this scenario revealed that the SDK client would retry uploads for non-mark-supporting streams on `IOException` in the `InputStream`.
39 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We were incorrectly handling
IOExceptionsthrown bythe
InputStreamside of the upload operation, resultingin a
ClassCastExceptionas we expected to never getIOExceptionfrom the Azure SDK code but we do in practice.This PR also sets an assertion on
markSupportedfor thestreams used by the SDK as adding the test for this scenario
revealed that the SDK client would retry uploads for
non-mark-supporting streams on
IOExceptionin theInputStream.