Fix ApiError.code fallback for Databricks-specific error codes#181
Draft
parthban-db wants to merge 1 commit into
Draft
Fix ApiError.code fallback for Databricks-specific error codes#181parthban-db wants to merge 1 commit into
parthban-db wants to merge 1 commit into
Conversation
|
Please ensure that the NEXT_CHANGELOG.md file is updated with any relevant changes. |
## Summary Fixes `ApiError.code` resolving to `Code.UNKNOWN` for every Databricks-specific error, and exposes the raw `error_code` string as a new `ApiError.errorCode` field so callers can match Databricks-specific codes precisely. ## Why Databricks APIs return product-specific error codes in the `error_code` field (e.g. a 404 with `"error_code": "CATALOG_DOES_NOT_EXIST"`). `ApiError.fromHttpError` called `codeFromString(error_code)` unconditionally for string codes, but `codeFromString` only knows the canonical gRPC code names; any Databricks-specific string is a table miss and returns `Code.UNKNOWN`. Only the non-string branch (integer or missing `error_code`) fell back to `toCode(httpStatusCode)`. As a result, the canonical `code` was `UNKNOWN` for essentially all real Databricks errors, so a guard like `if (err.code === Code.NOT_FOUND)` was always false even on a genuine 404. Callers also had no way to recover the original `error_code` string, so they could not match on Databricks-specific codes at all. This is a deliberate divergence from the Go SDK. The Go SDK has the identical canonical-code gap, but it always preserves the raw `error_code` string on a dedicated `APIError.ErrorCode` field. The TypeScript SDK had collapsed the error down to only the canonical `code`, dropping the raw string entirely. This PR closes the gap on both fronts: it adds the status-code fallback so the canonical `code` is meaningful, and it reintroduces the raw string as `errorCode` to match the information the Go SDK preserves. ## What changed ### Interface changes - **`ApiError.errorCode: string`** — New public readonly field carrying the raw, Databricks-specific error code string from the response (e.g. `"CATALOG_DOES_NOT_EXIST"`). It is `''` when the response did not carry a string error code. Use it to match codes that have no canonical `Code` equivalent. - **`ApiErrorOptions.errorCode?: string`** — New optional constructor option backing the field. ### Behavioral changes - When `error_code` is a string that does not map to a canonical `Code` (i.e. `codeFromString` returns `Code.UNKNOWN`), `fromHttpError` now falls back to `toCode(httpStatusCode)` instead of leaving `code` as `UNKNOWN`. A 404 with a Databricks-specific `error_code` now resolves `code` to `Code.NOT_FOUND`. Known canonical string codes (e.g. `"NOT_FOUND"`) continue to map directly, and integer or missing `error_code` values continue to fall back to the status code. The raw string is preserved on the new `errorCode` field regardless of whether the canonical mapping succeeded. ### Internal changes - Unified the string and non-string `error_code` paths in `fromHttpError`: the raw string (or `''`) is computed once, mapped through `codeFromString`, and falls back to `toCode(statusCode)` on a miss for both paths. ## How is this tested? Updated `packages/core/tests/apierror/apierror.test.ts`. The case that previously locked in the bug (a Databricks-specific string code asserting `Code.UNKNOWN`) now asserts the corrected status-code fallback (`CATALOG_DOES_NOT_EXIST` on a 404 resolves to `Code.NOT_FOUND` and preserves `errorCode`). The `fromHttpError` runner now also asserts `errorCode` on every case, and the known-canonical-string cases assert their preserved raw string. `npm run build`, `npm test` (357 tests pass), `npm run typecheck`, and `npm run lint` for `@databricks/sdk-core` are all clean. Co-authored-by: Isaac
parthban-db
force-pushed
the
parthban-db/stack/bugbash-bug2-apierror-code
branch
from
8671804 to
357b416
Compare
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
1 participant
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.
🥞 Stacked PR
Use this link to review incremental changes.
Summary
Fixes
ApiError.coderesolving toCode.UNKNOWNfor Databricks-specific errors and adds a new publicApiError.errorCodefield carrying the rawerror_codestring.Why
Databricks APIs return product-specific codes (e.g. a 404 with
"error_code": "CATALOG_DOES_NOT_EXIST"), butfromHttpErroronly fell back to the HTTP status code whenerror_codewas missing or an integer. For string codes it calledcodeFromStringunconditionally, which returnsCode.UNKNOWNfor any non-canonical name, socodewasUNKNOWNfor essentially all real errors and the raw string was discarded entirely. This restores a meaningful canonicalcodeand preserves the original string for direct matching.What changed
fromHttpErrornow falls back totoCode(httpStatusCode)when a stringerror_codedoes not map to a canonicalCode, so a 404 resolves toCode.NOT_FOUND; canonical strings and integer/missing codes are unchanged.ApiError.errorCode: string(and optionalApiErrorOptions.errorCode) holding the raw response string, or''when none was present.error_codebranches into one path that computes the raw string once, maps it, then falls back on a miss.APIError.ErrorCode; this brings the TypeScript SDK to parity and adds the status-code fallback.Validated:
@databricks/sdk-corebuild, tests (357 pass), typecheck, and lint all clean.