Created ErrorResponse to abstract error deserialization#1427
Merged
Conversation
3dee0c7 to
e2af00b
Compare
NachoSoto
commented
Mar 29, 2022
| @@ -17,11 +17,8 @@ enum UserInfoAttributeParser { | |||
|
|
|||
| static func attributesUserInfoFromResponse(response: [String: Any], statusCode: HTTPStatusCode) -> [String: Any] { | |||
Contributor
Author
There was a problem hiding this comment.
This whole class will go away soon, will be superseded by the new ErrorResponse.
Merged
10 tasks
f78f584 to
f1efdc8
Compare
aboedo
approved these changes
Mar 30, 2022
Member
There was a problem hiding this comment.
nice!!! this will also help us get rid of some hacky stuff we have like the finishableKey and RCSuccessfullySyncedKey, which were just awkward ways to communicate information through the same existing dictionary back to other layers
36cf996 to
b1ebd78
Compare
8f5e21d to
3ce751a
Compare
NachoSoto
added a commit
that referenced
this pull request
Mar 30, 2022
Follow up to #1427. Other changes: - Removed `UserInfoAttributeParser` - Simplified `JSONDecoder.decode` implementation by simply relying on `defaultJsonDecoder` - Added support for "wrapped" error responses. This was previously handled by `UserInfoAttributeParser`. - Removed all duplicated code parsing error responses - The new `ErrorResponse` introduced in #1427 correctly decodes the format sent by the backend. Note that some tests had the wrong format, and `UserInfoAttributeParser` was parsing that wrong as well. An upcoming PR will actually move these calls to `ErrorResponse` to `HTTPClient`.
101a97a to
cd7a551
Compare
3ce751a to
8c7435c
Compare
NachoSoto
added a commit
that referenced
this pull request
Apr 1, 2022
Follow up to #1427. Other changes: - Removed `UserInfoAttributeParser` - Simplified `JSONDecoder.decode` implementation by simply relying on `defaultJsonDecoder` - Added support for "wrapped" error responses. This was previously handled by `UserInfoAttributeParser`. - Removed all duplicated code parsing error responses - The new `ErrorResponse` introduced in #1427 correctly decodes the format sent by the backend. Note that some tests had the wrong format, and `UserInfoAttributeParser` was parsing that wrong as well. An upcoming PR will actually move these calls to `ErrorResponse` to `HTTPClient`.
cd7a551 to
7b42026
Compare
8c7435c to
37d47e9
Compare
NachoSoto
added a commit
that referenced
this pull request
Apr 1, 2022
Follow up to #1427. Other changes: - Removed `UserInfoAttributeParser` - Simplified `JSONDecoder.decode` implementation by simply relying on `defaultJsonDecoder` - Added support for "wrapped" error responses. This was previously handled by `UserInfoAttributeParser`. - Removed all duplicated code parsing error responses - The new `ErrorResponse` introduced in #1427 correctly decodes the format sent by the backend. Note that some tests had the wrong format, and `UserInfoAttributeParser` was parsing that wrong as well. An upcoming PR will actually move these calls to `ErrorResponse` to `HTTPClient`.
This is duplicated in most of the `NetworkOperation`s. This new shared implementation will be used by `HTTPClient`.
37d47e9 to
f3946de
Compare
NachoSoto
added a commit
that referenced
this pull request
Apr 1, 2022
Follow up to #1427. Other changes: - Removed `UserInfoAttributeParser` - Simplified `JSONDecoder.decode` implementation by simply relying on `defaultJsonDecoder` - Added support for "wrapped" error responses. This was previously handled by `UserInfoAttributeParser`. - Removed all duplicated code parsing error responses - The new `ErrorResponse` introduced in #1427 correctly decodes the format sent by the backend. Note that some tests had the wrong format, and `UserInfoAttributeParser` was parsing that wrong as well. An upcoming PR will actually move these calls to `ErrorResponse` to `HTTPClient`.
NachoSoto
added a commit
that referenced
this pull request
Apr 1, 2022
…1429) Follow up to #1427. The new way to create errors is like this: ```swift ErrorResponse .from(response) .asBackendError(with: statusCode) ``` ## Other changes: - Removed `UserInfoAttributeParser` - Simplified `JSONDecoder.decode` implementation by simply relying on `defaultJsonDecoder` - Added support for "wrapped" error responses. This was previously handled by `UserInfoAttributeParser`. - Removed all duplicated code parsing error responses - The new `ErrorResponse` introduced in #1427 correctly decodes the format sent by the backend. Note that some tests had the wrong format, and `UserInfoAttributeParser` was parsing that wrong as well. An upcoming PR will actually move these calls to `ErrorResponse` to `HTTPClient`.
NachoSoto
added a commit
that referenced
this pull request
Apr 12, 2022
…rkError` and `BackendError` (#1425) Closes #695 and finishes [CF-195]. Depends on ~~#1431, #1432, #1433, #1437~~. ## Goals: - [x] Handle all requests / response / deserialization errors in `HTTPClient`. Clients of `HTTPClient` will only have to handle the "happy" path: #1431 - [x] `HTTPClient` shouldn't return `Result.success` with failed responses, forcing clients to verify the response is actually a failure: #1431 - [x] Abstract error response deserialization / error creation: #1427 - [x] Abstract attribute error parsing: #1427 - [x] Move response deserialization to `HTTPClient` based on a `ResponseType: Decodable` type, so the completion block will simply return a `Result<HTTPResponse<ResponseType>, Error>` - [x] `ETagManager` should store response `Data` instead of a deserialized `[String: Any]` - [x] Improved error types in `HTTPClient` to fix tests: #1437 - [x] Dealt with non-backwards compatible `ETagManager: #1438 ## Changes: - Replaced `HTTPResponse`'s body from `[String: Any]` to a generic `HTTPResponseBody`. - Created `HTTPResponseBody` to abstract `Decodable` and provide some default implementations for types like `Data,` `[String: Any]` (for backwards compatibility to types that aren't `Decodable` yet), and `Decodable` itself. - New `HTTPResponse.Result` typealias (`Result<HTTPResponse<HTTPResponseBody>, Error>`) used everywhere. This will allow replacing `Error` with a more specific `Error` so we can forward known typed errors, and make sure that we don't end up with the wrong error type, or with a very complex error hierarchy and the details buried in `underlyingError`. - Each layer (only a few for now) has its own error type: `NetworkError`, `BackendError`, `OfferingsManager.Error`. - `HTTPClient` for example has to produce `NetworkError`, operations produce `BackendError` - The parent `BackendError` can have specific errors like `.missingAppUserID`, but also be simply a child error `case networkError(NetworkError)` - All of these conform to a `ErrorCodeConvertible`, so there is a single point of code that converts from simple and readable errors (like `BackendError.emptySubscriberAttributes`, `.unexpectedBackendResponse(.loginResponseDecoding)`) into errors with all the context using `ErrorUtils` - Converted `DNSError` into `NetworkError.dnsError`. Its functionality remains unchanged. - Removed `Backend.RCSuccessfullySyncedKey` and `ErrorDetails.finishableKey` in favor of tested properties on `NetworkError` ### Leftovers There's a few things I've decided to not finish for now: - [ ] `CustomerInfo` still does't conform to `Decodable` (manual deserialization is still supported by the current system): #1496 - `SubscriberAttributeDict` could also be `Codable` - [x] Replace `OfferingsFactory` with `Decodable`: #1435 [CF-195]: https://revenuecats.atlassian.net/browse/CF-195?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is duplicated in most of the
NetworkOperations. This new shared implementation will be used byHTTPClient.For #695.
See #1429 for how this is used.