fix: Filter null entities in listPrincipals and listPrincipalRoles to prevent NPE #2258
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
HotSushi
force-pushed
the
npe
branch
2 times, most recently
from
cdaeb0f to
430b04f
Compare
XN137
reviewed
Aug 5, 2025
Contributor
There was a problem hiding this comment.
the fix indeed avoids some NPEs but the fact that similar problems had to be fixed previously (and listCatalogRoles is still suffering from the same problem afaict) makes me believe the problem should be addressed in a more central spot.
from a high level perspective it should not be the responsibility of PolarisAdminService to deal with race-condition issues in the PolarisMetaStoreManager for simple operations like "load all entities of type X".
i've put up #2261 so that we can have a single place for the workaround while future work can look to improve the PolarisMetaStoreManager api in that regard.
if we think the added tests still provide additional value my suggestion would be to rebase your PR after the other PR has been merged, wdyt?
Contributor
Author
|
Thanks @XN137, agree if there's a better place for the fix to be checked in. Thank you for jumping in. After that fix, I do not think tests would serve additional benefit. Do use them verbatim if you like them in your PR. |
Member
|
Fixing the root cause sounds like the better path forwards. Provided a possible option in #2261 (review) |
snazy
pushed a commit
that referenced
this pull request
Aug 7, 2025
`PolarisAdminService` has multiple spots where it is working around the sub-optimal `PolarisMetaStoreManager` APIs. This results in multiple fixes like #1949 and #2258 While eventually the underlying APIs should be improved, for now we can make a single central workaround and clean up some redundant code. Also we can improve the return types as callers are not interested in details of the entity layer.
Contributor
|
since the other PR has been merged i'd suggest to close this PR now |
github-project-automation
bot
moved this from PRs In Progress
to Done
in Basic Kanban Board
snazy
added a commit
to snazy/polaris
that referenced
this pull request
Nov 20, 2025
* fix(deps): update dependency com.nimbusds:nimbus-jose-jwt to v10.4.1 (apache#2270) * chore(deps): update actions/download-artifact action to v5 (apache#2271) * fix(deps): update dependency boto3 to v1.40.3 (apache#2269) * Prefer diagnostics field in Resolver (apache#2247) * Stop mocking PolarisDiagnostics (apache#2248) if diagnostis checks are failing in our tests we want to know about it * Add TestServices.newCallContext (apache#2249) also add local `newCallContext` helper in some test classes * Nit: simplify runtime-service dependencies (apache#2273) Dependency "io.quarkus:quarkus-jdbc-postgresql" doesn't need any excludes (these excludes were for `SparkIT` which is now isolated in a separate module). * Minor fixes and enhancements to External IDP documentation (apache#2274) * Standardize logging libraries in tests (apache#2268) This change enforces the following test logging patterns: - Non-Quarkus modules use Logback Classic, configured via logback-test.xml - Quarkus modules use JBoss Logging Manager, configured in Quarkus configuration files. This change also introduces a workaround for the "duplicate log messages" issues with Gradle + JBoss Logging Manager. See this issue for context: quarkusio/quarkus#22844 The workaround implemented in this PR is very similar to the one proposed in this comment: quarkusio/quarkus#22844 (comment) Note: it's not entirely possible imho to suppress the following message on the console: ``` The Agroal dependency is present but no JDBC datasources have been defined. ``` This is because: 1. The message happens during augmentation phase, not during tests 2. And it suffers from the "duplicate message" issue with (it's actually Gradle that prints those messages). * Use Mockito Java agent for mock instrumentation (apache#2275) This change fixes the following warning during tests: Mockito is currently self-attaching to enable the inline-mock-maker. This will no longer work in future releases of the JDK. Please add Mockito as an agent to your build as described in Mockito's documentation: https://javadoc.io/doc/org.mockito/mockito-core/latest/org.mockito/org/mockito/Mockito.html#0.3 WARNING: A Java agent has been loaded dynamically (.../byte-buddy-agent-1.17.5.jar) WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information WARNING: Dynamic loading of agents will be disallowed by default in a future release * Use injected PolarisDiagnostics in MetaStoreManagerFactory impls (apache#2251) * Clean exit when running repair mode for client (apache#2287) * Clean exit when running repair mode for client * Clean exit when running repair mode for client * chore(deps): update dependency poetry to v2.1.4 (apache#2259) * chore(deps): update dependency poetry to v2.1.4 * fix pyproject --------- Co-authored-by: Robert Stupp <snazy@snazy.de> * fix(deps): update dependency com.gradleup.shadow:shadow-gradle-plugin to v9 (apache#2289) * chore(deps): update docker.io/jaegertracing/all-in-one docker tag to v1.72.0 (apache#2285) * fix(deps): update dependency boto3 to v1.40.4 (apache#2284) * Remove PolarisCallContext.getClock (apache#2250) the clock is application scoped and thus should not be put into any realm or call specific context class. * Add PolarisAdminService.loadEntities helper (apache#2261) `PolarisAdminService` has multiple spots where it is working around the sub-optimal `PolarisMetaStoreManager` APIs. This results in multiple fixes like apache#1949 and apache#2258 While eventually the underlying APIs should be improved, for now we can make a single central workaround and clean up some redundant code. Also we can improve the return types as callers are not interested in details of the entity layer. * fix(deps): update dependency com.google.cloud:google-cloud-storage-bom to v2.55.0 (apache#2281) * fix: typo in server template files. (apache#2288) * NoSQL: merge related adoptions * Last merged commit d753e3d --------- Co-authored-by: Mend Renovate <bot@renovateapp.com> Co-authored-by: Christopher Lambert <xn137@gmx.de> Co-authored-by: Alexandre Dutra <adutra@apache.org> Co-authored-by: Yong Zheng <yongzheng0809@gmail.com> Co-authored-by: Yujiang Zhong <42907416+zhongyujiang@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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
Similar to listCatalogs fix, these methods are non-atomic and can cause NPE when entities are deleted between listEntities and loadEntity calls. Added .filter(Objects::nonNull) to safely handle race conditions.
Similar to: #1949
Tagging reviewers from previous pr:
@eric-maynard
@dimas-b
@andrew4699
Tests
Added tests to verify null filtering behavior when entities are deleted after being listed but before being loaded.
✅
./gradlew buildsucceeds✅ Added unit tests