Skip to content

Surface API error messages and standardize HTTP status fallback messages#146

Merged
andyjohnsonsmarty merged 4 commits into
masterfrom
carter/shared-errors
Jun 18, 2026
Merged

Surface API error messages and standardize HTTP status fallback messages#146
andyjohnsonsmarty merged 4 commits into
masterfrom
carter/shared-errors

Conversation

@CarterSmarty

@CarterSmarty CarterSmarty commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

Summary

Implements the standard error message scheme shared across all Smarty SDKs: every HTTP error status now surfaces the message from the API's JSON error body ({"errors":[{"message":"..."}]}) when one is present, and falls back to the standard per-status message list otherwise (304, 400, 401, 402, 403, 408, 413, 422, 429, 500, 502, 503, 504, plus an "unexpected status code" default).

In this SDK

  • 400/401/402/403/408/413/422/429 now reject with their specific error classes (previously DefaultError); added ForbiddenError/RequestTimeoutError/BadGatewayError.
  • Every error class sets an explicit name so it survives minification and duplicate package copies; rejected.statusCode is unchanged for property-based checks.
  • Note for consumers: instanceof DefaultError checks for 4xx statuses will no longer match; use the specific classes, error.name, or statusCode.

Validation

  • Unit tests cover every handled status: API message preferred, exact standard fallback on empty/malformed/unusable bodies, unknown status codes, and unchanged 304/ETag behavior.
  • Verified against the live API with real credentials: 400 (missing street), 401 (bad credentials), 404 (unexpected-status path), and 422 (out-of-range latitude) each surfaced the server's own message through this SDK's full client chain.

Related PRs (same change in every SDK)

@andyjohnsonsmarty andyjohnsonsmarty left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a test that checks how non-enrichment-apis handle 304, they should return a positive result

HttpSender returns null for an empty body (no JSON.parse throw), and the
batch / us_autocomplete_pro / us_extract clients tolerate a null payload, so a
304 yields an empty result instead of throwing.
@andyjohnsonsmarty andyjohnsonsmarty self-requested a review June 18, 2026 20:07
@andyjohnsonsmarty andyjohnsonsmarty merged commit faf6054 into master Jun 18, 2026
@andyjohnsonsmarty andyjohnsonsmarty deleted the carter/shared-errors branch June 18, 2026 20:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants