You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MPP-4337 - feat(relay): improve API error handling to extract error c… (#6992)
* MPP-4337 - feat(relay): improve API error handling to extract error code and details from JSON
Update Relay error handling logic to parse both `error_code`
and `detail` fields from API error responses. This enables
propagating the exact error code (if present) alongside the
detail message when reporting API errors.
Introduces a helper to extract JSON API errors and updates
tests to cover new parsing logic for various error payload shapes.
* MPP-4337 - feat(relay): add HTTP status to errors
- Add `status: u16` to `RelayApiError::Api` and `Error::RelayApi` for richer error context.
- Update error reporting to expose `status`, `code`, and `detail` fields, allowing downstream users to inspect both raw server data and structured API error codes.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,6 +15,12 @@
15
15
- Updated the ApiError enum to AdsClientApiError to avoid naming collision.
16
16
- The `context_id` is now generated and rotated via the existing eponym component crate.
17
17
18
+
### Relay
19
+
- **⚠️ Breaking Change:** The error handling for the Relay component has been refactored for stronger forward compatibility and more transparent error reporting in Swift and Kotlin via UniFFI.
20
+
- API and network errors from the Relay server are now converted to a single `RelayApiError::Api { status, code, detail }` variant, exposing the HTTP status code, a machine-readable error code (if present), and a human-readable detail message.
21
+
- Downstream client apps can now handle server errors based on both the `status` and `error_code` fields directly, without additional changes to the Rust component - even as server-side error codes evolve.
22
+
- **Consumers must update their error handling code to match the new `Api { status, code, detail }` shape.**
/// Retrieves all Relay addresses associated with the current account.
113
108
///
114
-
/// Returns a vector of [`RelayAddress`] objects on success, or an error if the request fails.
109
+
/// Returns a vector of [`RelayAddress`] objects on success.
110
+
///
111
+
/// ## Errors
115
112
///
116
-
/// ## Known Limitations
117
-
/// - Will return an error if the Relay user record doesn't exist yet (see [`accept_terms`]).
118
-
/// - Error variants are subject to server-side changes.
113
+
/// - `RelayApi`: Returned for any non-successful (non-2xx) HTTP response. Provides the HTTP `status` and response `body`; downstream consumers can inspect these fields. If the response body is JSON with `error_code` or `detail` fields, these are parsed and included for more granular handling; otherwise, the raw response text is used as the error detail.
114
+
/// - `Network`: Returned for transport-level failures, like loss of connectivity, with details in `reason`.
115
+
/// - Other variants may be returned for unexpected deserialization, URL, or backend errors.
let addresses:Vec<RelayAddress> = response.json()?;
@@ -136,17 +138,27 @@ impl RelayClient {
136
138
///
137
139
/// This function was originally used to signal acceptance of terms and privacy notices,
138
140
/// but now primarily serves to provision (create) the Relay user record if one does not exist.
139
-
/// Returns `Ok(())` on success, or an error if the server call fails.
141
+
///
142
+
/// ## Errors
143
+
///
144
+
/// - `RelayApi`: Returned for any non-successful (non-2xx) HTTP response. Provides the HTTP `status` and response `body`; downstream consumers can inspect these fields. If the response body is JSON with `error_code` or `detail` fields, these are parsed and included for more granular handling; otherwise, the raw response text is used as the error detail.
145
+
/// - `Network`: Returned for transport-level failures, like loss of connectivity, with details in `reason`.
146
+
/// - Other variants may be returned for unexpected deserialization, URL, or backend errors.
140
147
#[handle_error(Error)]
141
148
pubfnaccept_terms(&self) -> ApiResult<()>{
142
149
let url = self.build_url("/api/v1/terms-accepted-user/")?;
143
150
let request = self.prepare_request(Method::Post, url)?;
/// - `generated_for`: The website for which the address is generated.
160
172
/// - `used_on`: Comma-separated list of all websites where this address is used. Only updated by some clients.
161
173
///
162
-
/// ## Open Questions
163
-
/// - See the spike doc and project Jira for clarifications on field semantics.
164
-
/// - Returned error codes are not fully documented.
174
+
/// ## Errors
165
175
///
166
-
/// Returns the newly created [`RelayAddress`] on success, or an error.
176
+
/// - `RelayApi`: Returned for any non-successful (non-2xx) HTTP response. Provides the HTTP `status` and response `body`; downstream consumers can inspect these fields. If the response body is JSON with `error_code` or `detail` fields, these are parsed and included for more granular handling; otherwise, the raw response text is used as the error detail.
177
+
/// - `Network`: Returned for transport-level failures, like loss of connectivity, with details in `reason`.
178
+
/// - Other variants may be returned for unexpected deserialization, URL, or backend errors.
0 commit comments