Fix REST responses for failed Admin operations #2291
Merged
Conversation
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
XN137
force-pushed
the
fix-admin-rest-responses
branch
from
c7b3a45 to
339ac46
Compare
snazy
reviewed
Aug 7, 2025
| return Response.status(Response.Status.BAD_REQUEST).build(); | ||
| } | ||
| return Response.status(Response.Status.CREATED).build(); | ||
| return toResponse(result, Response.Status.CREATED); |
Member
There was a problem hiding this comment.
This means that errors were not propagated to clients, right?
Contributor
Author
There was a problem hiding this comment.
yeah, some methods do throw exceptions internally (and those get propagated to clients correctly) but the returned boolean value of the methods was often ignored.
as part of this PR we have to fix a test in PolarisManagementServiceIntegrationTest.java which was silently failing before.
XN137
force-pushed
the
fix-admin-rest-responses
branch
3 times, most recently
from
9cf05b2 to
d9a55c1
Compare
the `boolean` return values of many methods in `PolarisAdminService` were often simply not getting used at all, thus the REST api returned success in those cases even though the `PrivilegeResult` was marked as failed. due to this fix a silently failing test now needs to be adjusted. we return the `PrivilegeResult` instead of a `boolean` to give the client at least some indication of what has gone wrong on the server side. note that some of the other operations were throwing Expcetions already, which are already reported back correctly to the client.
XN137
force-pushed
the
fix-admin-rest-responses
branch
from
d9a55c1 to
56ad6dc
Compare
XN137
commented
Aug 12, 2025
| .returns(Response.Status.INTERNAL_SERVER_ERROR.getStatusCode(), Response::getStatus); | ||
| assertThat(response.hasEntity()).isTrue(); | ||
| ErrorResponse errorResponse = response.readEntity(ErrorResponse.class); | ||
| assertThat(errorResponse.message()).contains("Operation failed: GRANT_NOT_FOUND"); |
Contributor
Author
There was a problem hiding this comment.
there could be an argument that GRANT_NOT_FOUND should be a 404 instead of internal server error but it would mean we need to translate all BaseResult.ReturnStatus values to a proper HTTP code.
i think this can be figured out in a followup and we should first stop silently failing in those cases.
Member
There was a problem hiding this comment.
Hm - HTTP/500 feels odd, as it's rather a user (argument) error. HTTP/400 would be better IMHO.
Contributor
Author
There was a problem hiding this comment.
ok switched to HTTP/400
snazy
approved these changes
Aug 12, 2025
github-project-automation
bot
moved this from PRs In Progress
to Ready to merge
in Basic Kanban Board
dimas-b
approved these changes
Aug 12, 2025
adutra
approved these changes
Aug 12, 2025
Member
|
If nobody objects, I'll merge later today. |
github-project-automation
bot
moved this from Ready to merge
to Done
in Basic Kanban Board
snazy
added a commit
to snazy/polaris
that referenced
this pull request
Nov 20, 2025
* Fix Keycloak getting-started example (apache#2349) The `polaris-setup` container was erroneously including a non-existent scope when fetching a token from Keycloak. * fix(deps): update dependency com.nimbusds:nimbus-jose-jwt to v10.4.2 (apache#2350) * Use PolarisTaskConstants (apache#2346) * Add a regression test for Catalog Federation (apache#2286) * Add a regression test for Catalog Federation * Install jq dependency * Fix token issues * Update regtests/README.md Co-authored-by: Eric Maynard <[email protected]> * Update README.md --------- Co-authored-by: Eric Maynard <[email protected]> * Modularize federation (Option 2) (apache#2332) * Modularize federation (Option 2) * Move polaris-extensions-federation-hadoop dependency * Change identifier to lowerCase * Change identifiers to constants * Replace CallContext with RealmConfig in enforceFeatureEnabledOrThrow (apache#2348) * Replace CallContext with RealmConfig in CatalogEntity (apache#2336) * chore(deps): update registry.access.redhat.com/ubi9/openjdk-21-runtime docker tag to v1.23-6 (apache#2353) * fix(deps): update dependency com.gradleup.shadow:shadow-gradle-plugin to v9.0.2 (apache#2358) * chore(deps): update postgres docker tag to v17.6 (apache#2354) * Add integration tests with Keycloak (apache#2343) * Fix REST responses for failed Admin operations (apache#2291) * Fix REST responses for failed Admin operations the `boolean` return values of many methods in `PolarisAdminService` were often simply not getting used at all, thus the REST api returned success in those cases even though the `PrivilegeResult` was marked as failed. due to this fix a silently failing test now needs to be adjusted. we return the `PrivilegeResult` instead of a `boolean` to give the client at least some indication of what has gone wrong on the server side. note that some of the other operations were throwing Expcetions already, which are already reported back correctly to the client. * review: use http 400 BAD_REQUEST * Make PolarisAuthorizer RequestScoped (apache#2340) all methods in `PolarisAuthorizer` currently have a `CallContext` parameter. in its only implementation only `CallContext.getRealmConfig` is getting used. so since `PolarisAuthorizer` cant be used outside a request, we can simply make it request-scoped and inject the request-scoped `RealmConfig` directly. * fix(deps): update mockito monorepo to v5.19.0 (apache#2360) * Fix soft-merge conflict on `main` (apache#2364) * feat(docs): Add Getting Stated guide for MinIO (apache#2227) * feat(docs): Add Getting Stated guide for MinIO A simple page of step-by-step instructions for setting up a local environment with Polaris, MinIO and Spark. Closes apache#1530 * IntelliJ: fix project icon in IJ project list (apache#2366) ... copy source has changed * Use asMap property helpers (apache#2347) seems like these helpers existed for a long time but were just not getting used consistently * SigV4 Auth Support for Catalog Federation - Part 2: Connection Config Persistence (apache#2190) * Add SigV4 related DPOs * Rename UserSecretReference to SecretReference and fix some small issues * fix(deps): update dependency software.amazon.awssdk:bom to v2.32.24 (apache#2371) * Rat-check: exclude venv, cleanup excludes, include .svg (apache#2363) * `.svg` files are XML files and can contain a license header * Re-grouped the exclusion rat patterns * Added exclude for `.venv` * Added exclude for `.ruff_cache` * NoSQL: Async-impls: add some safeguards + javadoc spelling * NoSQL: spelling * NoSQL: dependency updates * Last merged commit: 5a7686b --------- Co-authored-by: Alexandre Dutra <[email protected]> Co-authored-by: Mend Renovate <[email protected]> Co-authored-by: Christopher Lambert <[email protected]> Co-authored-by: Pooja Nilangekar <[email protected]> Co-authored-by: Eric Maynard <[email protected]> Co-authored-by: Dmitri Bourlatchkov <[email protected]> Co-authored-by: Rulin Xing <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
the
booleanreturn values of many methods inPolarisAdminServicewere often simply not getting used at all, thus the REST api returned
success in those cases even though the
PrivilegeResultwas markedas failed.
due to this fix a silently failing test now needs to be adjusted.
we return the
PrivilegeResultinstead of abooleanto give theclient at least some indication of what has gone wrong on the server
side.
note that some of the other operations were throwing Expcetions already,
which are already reported back correctly to the client.