fix!: Throw error on invalid encoded data in response #984
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
jbelkins
commented
Oct 22, 2025
| let traceInterceptor = TraceInterceptor<TestInput, TestOutput, HTTPRequest, HTTPResponse>(trace: trace) | ||
| let builder = OrchestratorBuilder<TestInput, TestOutput, HTTPRequest, HTTPResponse>() | ||
| .attributes(attributes) | ||
| .serialize({ input, builder, _ in |
Contributor
Author
There was a problem hiding this comment.
The tests below used JSON fragments (i.e. a JSON string only) for serde since fragments were allowed and it kept the test setup simpler. Tests now serialize JSON objects so the allowFragments option on the JSON reader can be disabled.
jbelkins
changed the title
…swift into jbe/invalid_json_fix
jbelkins
commented
Nov 24, 2025
| } catch let error as NSError where error.domain == "NSCocoaErrorDomain" && error.code == 3840 { | ||
| return try Reader(nodeInfo: "", jsonObject: [:]) | ||
| } catch { | ||
| throw InvalidEncodingError(wrapped: error) |
Contributor
Author
There was a problem hiding this comment.
Above:
- Explanatory comments are added
- JSON fragments are no longer allowed (no real services use them)
ResponseEncodingError(which wraps the spacific error thrown by the decoding implementation) is thrown when the JSON cannot be decoded
jbelkins
commented
Nov 24, 2025
| guard let doc = xmlReadMemory(buffer.pointee.content, Int32(count), "", "UTF-8", 0) else { return Reader() } | ||
| guard let doc = xmlReadMemory(buffer.pointee.content, Int32(count), "", "UTF-8", 0) else { | ||
| throw InvalidEncodingError(wrapped: XMLError.parsingError) | ||
| } |
Contributor
Author
There was a problem hiding this comment.
Instead of returning an empty parsed body, throw an ResponseEncodingError when the XML is not valid.
jbelkins
changed the title
jbelkins
commented
Nov 24, 2025
| XCTAssertThrowsError(try Reader.from(data: invalidXML)) { error in | ||
| XCTAssert(error is ResponseEncodingError) | ||
| } | ||
| } |
Contributor
Author
There was a problem hiding this comment.
Test above verifies that ResponseEncodingError is thrown for invalid XML.
sichanyoo
reviewed
Nov 24, 2025
| @@ -0,0 +1,28 @@ | |||
| // | |||
Contributor
There was a problem hiding this comment.
- Should this file name be changed from
InvalidEncodingErrorto match the error struct name - This may be wrong but shouldn't the error name be
ResponseDecodingErrorinstead ofResponseEncodingErrorsince SDK client is decoding response rather than encoding it
Contributor
Author
There was a problem hiding this comment.
Renamed as recommended
dayaffe
approved these changes
Nov 25, 2025
sichanyoo
approved these changes
Nov 25, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
Description of changes
Currently, when a response contains invalid JSON, the error is caught & not rethrown, and the response body is treated as an empty JSON object
{}.This can lead to misleading responses, i.e. leading the caller to believe that the request succeeded but returned no results versus that it was not parseable.
The error that is now thrown for an unparseable response is
SmithySerialization.ResponseEncodingError. This error "wraps" the specific error thrown by the parsing implementation, which hides both the implementation & the specific encoding in use. This module & name were chosen to be compatible with future planned changes to smithy-swift.guardthat handles the empty-response case now has some commentary to explain why it's there.NSErrorthat is thrown when JSON is invalid, and converting it to a successful response. That catch is now removed.nil. That behavior is unchanged.This is a breaking change in that it alters the SDK's behavior from "empty success" to throwing when unparseable data is encountered in a response. The impact should be minimal because invalidly encoded responses should never be happening on AWS services. (This was found in a cross-SDK investigation.)
Scope
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.