Preserve the raw Databricks error code on ApiError.code and stop translating HTTP status into a code

[parthban-db]

🥞 Stacked PR

Use this link to review incremental changes.

• stack/bugbash-bug2-apierror-code [Files changed]

---

Summary

Reworks ApiError.code to carry the response's error_code string verbatim — typed as an open enum whose named members are the canonical gRPC codes — and stops translating the HTTP status into a code. A 404 with "error_code": "CATALOG_DOES_NOT_EXIST" now exposes code === 'CATALOG_DOES_NOT_EXIST' instead of collapsing to Code.UNKNOWN, while a response with no string error_code is Code.UNKNOWN rather than a status-derived guess such as Code.NOT_FOUND.

Why

Databricks APIs return product-specific error codes (e.g. CATALOG_DOES_NOT_EXIST, INVALID_PARAMETER_VALUE) in the body's error_code field. fromHttpError resolved code by passing that string through codeFromString, which recognizes only the 17 canonical gRPC names and returns Code.UNKNOWN for anything else — so code was UNKNOWN for essentially every other Databricks error, a guard like if (err.code === Code.NOT_FOUND) was dead even on a genuine 404, and the original string was discarded with no way to recover it. When error_code was missing or an integer, code instead came from toCode, which maps the HTTP status to a canonical code (404 → NOT_FOUND, 400 → INVALID_ARGUMENT, and so on), but the heuristic may not always work.

How is this tested?

apierror.test.ts and codes.test.ts cover the cases above. @databricks/sdk-core format, lint, typecheck, test, and test:browser pass, as do the @databricks/sdk-examples checks.

AI Generated

What changed

Interface changes

• Code becomes an open string enum — export const Code = { UNKNOWN: 'UNKNOWN', … } as const plus export type Code = (typeof Code)[keyof typeof Code] | (string & {}) — replacing the numeric enum Code. Member spellings are unchanged (Code.NOT_FOUND, etc.); their values are now their own canonical strings rather than integers, and any string is a valid Code.
• ApiError.code: Code now holds the raw error_code string (canonical or product-specific), or Code.UNKNOWN when the response carries no string error code.
• Removed toCode (the exported HTTP-status → Code mapping function), along with codeToString and codeFromString: the SDK no longer derives a code from the status, and a Code is already its own string form.

Behavioral changes

• The HTTP status is no longer translated into a code. The toCode mapping (404 → NOT_FOUND, 400 → INVALID_ARGUMENT, 401 → UNAUTHENTICATED, non-canonical 4xx → FAILED_PRECONDITION, 5xx → INTERNAL, …) is gone. Any response without a usable string error_code — missing, an integer, an empty body, a non-JSON/proxy body, or one that fails schema validation — now yields Code.UNKNOWN instead of a status-derived code. Read httpStatusCode for status-based classification.
• A string error_code is carried verbatim: "NOT_FOUND" resolves to Code.NOT_FOUND, and "CATALOG_DOES_NOT_EXIST" resolves to 'CATALOG_DOES_NOT_EXIST' (previously Code.UNKNOWN).
• message, details, httpStatusCode, httpHeader, and httpBody are unchanged.

Internal changes

• fromHttpError assigns code directly from error_code; the toCode function and the CODE_TO_STRING / STRING_TO_CODE lookup tables are deleted.
• codes.test.ts is rewritten to cover the open enum (it previously exercised codeToString/codeFromString round-trips); apierror.test.ts cases are updated so a product-specific error_code asserts the verbatim code and responses with no string error_code assert Code.UNKNOWN.
• The auth-and-errors example logs err.code directly instead of codeToString(err.code).

[github-actions]

Please ensure that the NEXT_CHANGELOG.md file is updated with any relevant changes.
If this is not necessary for your PR, please include the following in your PR description:
NO_CHANGELOG=true
and rerun the job.

[mihaimitrea-db]

This test feels like your testing JavaScript. There's no logic behind this, just an export which you are verifying here. Am I reading this wrong?