feat(http): map 4xx/5xx responses to typed SDK errors (closes #2)

[dchaudhari7177]

Closes #2.

Every non-ok response except 401/403 became a generic LilyApiError, so callers had to read statusCode or parse the body to tell "not found" from "rate limited".

Mapping

Status	Error	code
400, 422	LilyValidationError	VALIDATION_ERROR
401	LilyAuthenticationError	AUTHENTICATION_ERROR
403	LilyAuthorizationError	AUTHORIZATION_ERROR
404, 410	LilyNotFoundError	NOT_FOUND
409	LilyConflictError	CONFLICT
429	LilyRateLimitError (+ retryAfterSeconds)	RATE_LIMITED
5xx	LilyServerError	SERVER_ERROR
other	LilyApiError	API_ERROR

The new classes extend LilyApiError (and LilyAuthorizationError extends LilyAuthenticationError), so existing instanceof checks keep working — there are tests asserting exactly that, since it's the thing a mapping change most easily breaks.

Retry-After is only reported in its delta-seconds form. The HTTP-date form would mean guessing at clock skew, so it's left undefined rather than wrong.

Not leaking secrets

Errors now carry a redacted bodySnippet next to the full details. Values under keys matching pass|secret|token|api[-_]?key|authorization|credential|signature|private are replaced with [redacted], recursively.

Redaction happens before truncation, which is the point — an error body is exactly where an API echoes back the credential it just rejected, and a 20-character token fits comfortably inside any length limit. There's a test for that specific ordering.

Cyclic bodies render as [circular] rather than making JSON.stringify throw and losing the snippet entirely.

One bug this surfaced

The catch block rethrew only LilyApiError and LilyAuthenticationError. LilyValidationError extends LilySdkError directly, so a mapped 400 was being caught and re-wrapped as a LilyTransportError, losing statusCode and details. My 400/422 tests failed on exactly this before I spotted it.

Fixed by rethrowing any LilySdkError. An explicit list of subclasses silently mis-wraps whatever isn't on it, which is how this happened in the first place.

Tests

22 added in tests/error-mapping.test.ts, driven through the real createFetchHttpClient with a mocked fetch rather than calling the mapper directly:

• each status → class → code triple, including the representative 400/401/404/500 the issue asks for
• all mapped errors remain LilySdkError; all non-auth ones remain LilyApiError
• Retry-After in both seconds and HTTP-date form
• redaction of nested and differently-cased secret keys, and redact-before-truncate
• truncation length and ellipsis, plain-text bodies, cyclic bodies, empty bodies
• details still carries the full parsed body

Gate

Windows / Node 20:

• npx vitest run — 29 passed (7 before this branch)
• npx tsc --project tsconfig.json --noEmit — clean (repo has exactOptionalPropertyTypes, so the new optional fields are declared ?: T | undefined)
• npx eslint . — clean

npm run format:check isn't usable as a signal here: prettier --check reports 45 files on pristine main in this checkout, because the files land CRLF on Windows against the configured LF. I left it alone rather than reformatting the repo inside this PR — happy to add a .gitattributes in a separate one if that's useful.

🤖 Generated with Claude Code

[carldesbiens-ui]

Addressed in #166.

Error mapping — already implemented, added tests — implementation + tests included.

Bounty: $0

[carldesbiens-ui]

Addressed in #166.

Error mapping — already implemented, added tests — implementation + tests included.

Bounty: $0