Fix error type for non-JSON error responses#758
Merged
renaudhartert-db merged 5 commits intomainfrom Apr 14, 2026
Merged
Conversation
When the server returns a plain-text error (e.g. "Invalid Token" with
HTTP 403), parseUnknownError set the error code to "UNKNOWN", which
matched ErrorMapper's errorCodeMapping and short-circuited the status
code mapping. This caused all non-JSON errors to produce Unknown instead
of the correct typed exception (PermissionDenied, Unauthenticated, etc.).
The root cause was that parseUnknownError assumed response.getStatus()
returned "403 Forbidden" but it only returns the reason phrase
("Forbidden"). The split-on-space logic always fell into the default
"UNKNOWN" branch.
The fix removes the error code derivation entirely, leaving errorCode
null so AbstractErrorMapper falls through to the status code mapping.
The error message now uses the raw response body instead of appending
Jackson parse exception details.
Co-authored-by: Isaac
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
renaudhartert-db
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
Avoid NPE in downstream .equals() and Pattern.matcher() calls when the error response cannot be parsed as JSON. Co-authored-by: Isaac
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
renaudhartert-db
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
The <pre> content extraction was accidentally removed, causing null error messages for HTML error responses. Co-authored-by: Isaac
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
renaudhartert-db
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
Contributor
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
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
2 participants
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.
Summary
When the server returns a plain-text error response (e.g.
"Invalid Token"with HTTP 403), the SDK throwsUnknowninstead ofPermissionDenied.The root cause:
parseUnknownErrorderives an error code by splittingresponse.getStatus()on space, expecting"403 Forbidden". ButCommonsHttpClientpassesstatusLine.getReasonPhrase(), which is just"Forbidden". The split produces one element, so error code defaults to"UNKNOWN", which matchesErrorMapper's error code mapping and short-circuits the status code mapping that would have correctly producedPermissionDenied.The fix removes the error code derivation entirely. Leaving
errorCodenull letsAbstractErrorMapper.applyskip the error code mapping and fall through to the status code mapping (403 ->PermissionDenied, 401 ->Unauthenticated, etc.). The error message now uses the raw response body instead of appending Jackson parse exception details.Behavioral change: non-JSON error responses now produce typed exceptions based on HTTP status code instead of always producing
Unknown. The error message no longer contains Jackson deserialization internals.Test plan
PlainTextErrorTestcovers: plain-text 403/401/404, HTML<pre>extraction, empty body, null bodymvn test -pl databricks-sdk-java)