-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Catch task description error #12834
Catch task description error #12834
Conversation
Signed-off-by: dblock <[email protected]>
No, I don't, thanks @andrross , I also feel like this is the direction we should be taking, I've suggested a bit more wider fix here #12834 (comment) |
Signed-off-by: dblock <[email protected]>
@reta implemented your suggested approach + test |
server/src/main/java/org/opensearch/action/search/SearchRequest.java
Outdated
Show resolved
Hide resolved
Signed-off-by: dblock <[email protected]>
A bit of a side note, given that a linear ring is a line string with some special constraints (start and end point must be the same), I wonder why |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #12834 +/- ##
============================================
- Coverage 71.42% 71.31% -0.11%
- Complexity 59978 60170 +192
============================================
Files 4985 5011 +26
Lines 282275 283664 +1389
Branches 40946 41117 +171
============================================
+ Hits 201603 202294 +691
- Misses 63999 64595 +596
- Partials 16673 16775 +102 ☔ View full report in Codecov by Sentry. |
Hard to say to be fair, wanna take a look? ;-) |
❕ Gradle check result for 71d3f02: UNSTABLE
Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure. |
It's all yours @dblock ! |
The backport to
To backport manually, run these commands in your terminal: # Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-12834-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 0c956e81373c9d5878710c1bafe471431000a64f
# Push it to GitHub
git push --set-upstream origin backport/backport-12834-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x Then, create a pull request where the |
@dblock could you please backport to 2.x manually? thank you! |
sb.append("source["); | ||
try { | ||
sb.append(source.toString(FORMAT_PARAMS)); | ||
} catch (final OpenSearchException ex) { |
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.
@reta / @dblock / @andrross : This is not right. buildDescription() shouldn't swallow exception. Anything unexpected should fail the request as early as possible. Earlier, IOException was wrapped and thrown and now that also gets swallowed. Why an object which is throwing UnsupportedOperationException not handled properly and reached till here at all? In order to fix an user behavior (which may not be an issue, as actual request may not reach till this point as well, unless someone has tested an actual user rest request and confirmed the behavior?). Tomorrow, somebody would wrap NPE also as OpenSearchException and start swallowing here as apparently buildDescription should succeed for some reason.
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.
Why an object which is throwing UnsupportedOperationException not handled properly and reached till here at all?
@shwetathareja There are few levels this exception will be raised and it will be handled properly, it is not swallowed. The issue that the description of the request (serialization of the POJO) - the string representation - triggers the problem first, even before the request is processed (and validated). So the suggested fix here is to provide partial description of the request that will eventually fail for exactly the same cause. This is what tests are verifying - the request fails with UnsupportedOperationException
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.
Specifically in the request path the request is read, then traced (including its description, which throws exception), then validated & al. If we switch the order of things and decide whether the request should be accepted before tracing it, then tracing will fail to show what the request being validated was.
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.
When the rest request will come, first the request has to be parsed/ deserialized, shouldn't it fail there, rather fail during serialization flow which comes after that.
I tried indexing and search linearring
shape type with trace logging enabled on OpenSearch 2.11 cluster.
trace logging enabled
"logger": {
"org": {
"opensearch": {
"tasks": "TRACE"
}
}
}
Below are the errors, I got:
During Indexing:
"caused_by": {
"type": "illegal_argument_exception",
"reason": "No enum constant org.opensearch.geometry.ShapeType.LINERRING"
}
During search
"caused_by": {
"type": "illegal_argument_exception",
"reason": "unknown geo_shape [linearring]"
}
The error during search is as expected from the parsing flow:
OpenSearch/server/src/main/java/org/opensearch/common/geo/parsers/GeoJsonParser.java
Line 85 in 4010ff1
final GeoShapeType type = GeoShapeType.forName(subParser.text()); |
Do you have an example of a rest request which will reach the serialization error ( from .getDescription()) which is fixed in the code above or the validation error you mentioned.
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.
It is not an end-to-end test, The test simply testing a particular flow for GeoShapeQueryBuilder
and expecting an exception.
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.
The builder could validate the supported shapes in
AbstractGeometryQueryBuilder
when creating the POJO itself.
I already replied to that here #12834 (comment)
I think the ideal option is @andrross 's idea to get rid of LinearRing if possible - this is supporting abstraction
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.
@dblock : Are you reverting this change?
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.
No, I am still convinced that the implementation merged here is better than what we had. Today tasks can fail to getDescription()
and the better place to guard it is in the code we added it in. If we get rid of LinearRing
, then we don't need to protect from failed serialization.
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.
Once we remove the Linearring, the only exception, you are taking care in getDescription() is IOException which we shouldn't catch and swallow even for getDescription() to work. I don't think there is need for this exception handling considering it has always been like this, not impacting any other tests/ flow yet.
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 agree re:once we remove the Linearring. I opened #12910, I'll try to get to it.
* Always return a task description even when it cannot be serialized. Signed-off-by: dblock <[email protected]> * Expect tasks to fail. Signed-off-by: dblock <[email protected]> * Only catch exceptions when getting description. Signed-off-by: dblock <[email protected]> * Added <error: ...> to mark error more clearly. Signed-off-by: dblock <[email protected]> --------- Signed-off-by: dblock <[email protected]> (cherry picked from commit 0c956e8)
* Always return a task description even when it cannot be serialized. Signed-off-by: dblock <[email protected]> * Expect tasks to fail. Signed-off-by: dblock <[email protected]> * Only catch exceptions when getting description. Signed-off-by: dblock <[email protected]> * Added <error: ...> to mark error more clearly. Signed-off-by: dblock <[email protected]> --------- Signed-off-by: dblock <[email protected]> (cherry picked from commit 0c956e8)
* Always return a task description even when it cannot be serialized. Signed-off-by: dblock <[email protected]> * Expect tasks to fail. Signed-off-by: dblock <[email protected]> * Only catch exceptions when getting description. Signed-off-by: dblock <[email protected]> * Added <error: ...> to mark error more clearly. Signed-off-by: dblock <[email protected]> --------- Signed-off-by: dblock <[email protected]> (cherry picked from commit 0c956e8)
* Always return a task description even when it cannot be serialized. Signed-off-by: dblock <[email protected]> * Expect tasks to fail. Signed-off-by: dblock <[email protected]> * Only catch exceptions when getting description. Signed-off-by: dblock <[email protected]> * Added <error: ...> to mark error more clearly. Signed-off-by: dblock <[email protected]> --------- Signed-off-by: dblock <[email protected]> Signed-off-by: Shivansh Arora <[email protected]>
Description
Alternative to (just the first two commits) to #12831.
A user that enables trace-level logging with OpenSearch will run into a serialization error on geo tasks that they otherwise would not run into. It comes from here. This also happens in a test, and #12783 attempts to ignore the failed serialization error. This PR always returns a task description.
Reproduce with
Related Issues
Closes #11688
Closes #12324
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.