-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
ASF: handle error serialization for Query-compatible services #13172
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
Conversation
Test Results - Alternative Providers73 tests 39 ✅ 3m 32s ⏱️ Results for commit d7d6848. ♻️ This comment has been updated with latest results. |
Test Results (amd64) - Integration, Bootstrap 5 files 5 suites 2h 35m 38s ⏱️ Results for commit d7d6848. ♻️ This comment has been updated with latest results. |
LocalStack Community integration with Pro 2 files ±0 2 suites ±0 1h 58m 5s ⏱️ +46s Results for commit d7d6848. ± Comparison against base commit 0809063. This pull request removes 3 and adds 10 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
alexrashed
left a comment
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.
Nice! Really great findings, and great that you are going a step further to increase the generalization based on the findings in the project! 💯 🦸🏽
|
|
||
|
|
||
| @pytest.fixture(params=["query", "json", "smithy-rpc-v2-cbor"]) | ||
| def aws_cloudwatch_client(aws_client, monkeypatch, request) -> "CloudWatchClient": |
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.
praise: Absolutely great! This means that we run all the tests which use this fixture against the different protocols! 🤩
| body["__type"] = error.code | ||
| # this depends on the JSON protocol version as well. If json-1.0 the Error should be the full shape ID, like | ||
| # com.amazon.coral.service#ExceptionName | ||
| # if json-1.1, it should only be the name |
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.
praise: Nice find! 💯
question: Is it maybe only json version specific, and the TODO is now actually done?
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.
Right now, I left the behavior as json-1.1 like it somewhat was before. I'm not sure we will be able to fully fix this anytime soon, because the prefix is highly dependent on the exception itself and where it is raised. Example:
CloudWatch ResourceNotFound -> com.amazonaws.cloudwatch.v2010_08_01#ResourceNotFound
CloudWatch ValidationException -> com.amazon.coral.validate#ValidationException
Clients are supposed to ignore what is put before #, so maybe we can safely ignore, but I think it's good to have this behavior written down somewhere to keep track of it.
So it's not addressed yet, and I'll want to test more about this in the future 👍
| "QueueNameExists": "QueueAlreadyExists", | ||
| } | ||
|
|
||
| def _serialize_error( |
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.
praise: Nice! Removing this / moving this handling to the superclass means more generalization! 💯
Motivation
This PR is part of a bigger initiative (see #13028) to implement support for the new Smithy Protocol
smithy-rpc-v2-cbor, as well as the new Botocore multi-protocol support for single services (before, a service could only define one protocol)This PR implements the utility/parametrized fixture to start running the full CloudWatch test suite with multiple protocols. I already encountered a few issues, so decided to already open a PR and work in smaller chunks.
This PR tackles mostly the error serialization for query compatible services (they are indicated via a field in their specs).
Those service will need to return a special header (
x-amzn-query-error) to help the client have the proper error serialization, see the boto handling here: https://github.com/boto/botocore/blob/de187f398ba981be728e3c69f23d6b634d555016/botocore/parsers.py#L399For the AWS Query compatible service, when they are working with JSON, they will put the shape name as the
__typefield.Looking at the spec, it seems the
jsonprotocol actually requires to use the shape name and not theerror.codefield when serializing error response: https://smithy.io/2.0/aws/protocols/aws-json-1_1-protocol.html#operation-error-serializationI believe this might be the case of all
jsonexception, but we did not realize it because for most services in their specs, we fallback to theshape.namein our scaffold script if theerror.codefield is not defined. For now, I'll contain this change to AWS query compatible services.I also added a small fix in the CloudWatch service itself regarding the type of a return value that would fail in the JSON protocol.
Changes
x-amzn-query-errorwhen necessary, allowing client to properly handle errorsjsonserializer to use the shape name for query compatible service (to investigate if its actually all the time)x-amzn-query-errorlogic