Bounty: $40 (LT)
Area: frontend/src/services/api.ts
Current state: The shared frontend API client parses every HTTP response into an ApiResponse<T> and returns it even when fetch receives non-2xx responses. As a result, 4xx/5xx responses can flow through response interceptors as successful data, the default error interceptors for 401/429 are not reliably exercised, and callers have to duplicate status checks. The parser also does not preserve structured error payload details from the backend.
What's needed: Update the TypeScript API service so non-OK HTTP responses are normalized into ApiError objects, run through the existing error interceptor chain, and thrown consistently while preserving request IDs, status codes, response body details, and actionable suggestions. Add focused tests or documented validation covering success, JSON error, text error, timeout, and network failure paths.
Acceptance criteria:
request<T>() rejects on non-2xx HTTP statuses instead of returning them as successful ApiResponse<T> values.- JSON and text error bodies are safely parsed and mapped into
ApiError.message, details, requestId, and path where available.
- Existing error interceptors continue to run for normalized HTTP errors, including 401 and 429 responses.
- Timeout and network-error behavior remains compatible with the current
normalizeError handling.
- Add or update validation notes/tests demonstrating 2xx success, 401 JSON error, 429 rate-limit error, 500 text error, and aborted request behavior.
Required validation:
- Run
python3 build.py
- Include the generated diagnostic
.logd artifact from diagnostic/build-XXX.logd in the PR; also include diagnostic/build-XXX.json if present
- Use
.github/pull_request_template.md for your submission
Bounty: $40 (LT)
Area:
frontend/src/services/api.tsCurrent state: The shared frontend API client parses every HTTP response into an
ApiResponse<T>and returns it even whenfetchreceives non-2xx responses. As a result, 4xx/5xx responses can flow through response interceptors as successful data, the default error interceptors for 401/429 are not reliably exercised, and callers have to duplicate status checks. The parser also does not preserve structured error payload details from the backend.What's needed: Update the TypeScript API service so non-OK HTTP responses are normalized into
ApiErrorobjects, run through the existing error interceptor chain, and thrown consistently while preserving request IDs, status codes, response body details, and actionable suggestions. Add focused tests or documented validation covering success, JSON error, text error, timeout, and network failure paths.Acceptance criteria:
request<T>()rejects on non-2xx HTTP statuses instead of returning them as successfulApiResponse<T>values.ApiError.message,details,requestId, andpathwhere available.normalizeErrorhandling.Required validation:
python3 build.py.logdartifact fromdiagnostic/build-XXX.logdin the PR; also includediagnostic/build-XXX.jsonif present.github/pull_request_template.mdfor your submission