bharos opened a new pull request, #11981: URL: https://github.com/apache/gravitino/pull/11981
### What changes were proposed in this pull request? `JcasbinAuthorizer.loadPolicyByRoleEntity` skips a securable object whose metadata id cannot be resolved (`resolveMetadataId` returns empty) via `continue`, but `versionCheckAndLoadRoles` still records the role in `loadedRoles` at the current version. As a result, if the id lookup for a securable object *transiently* fails during a policy reload — for example right after the `loadedRoles` TTL evicts the role while the catalog/entity resolution is momentarily unavailable — an **incomplete (under-granting) policy is cached as "fully loaded"** and served on every subsequent request until the next cache eviction (`GRAVITINO_AUTHORIZATION_CACHE_EXPIRATION_SECS`, default 3600s). Authorization does **not** self-heal once resolution recovers. This change makes `loadPolicyByRoleEntity` report whether **every** securable object resolved. The caller only marks the role loaded on a complete load; on an incomplete load it drops the partial policy and leaves the role uncached, so the next authorization reloads it and self-heals. Note on trade-off: a role that references a *permanently* dropped metadata object will now reload each request until its securable objects are cleaned up. If maintainers prefer, `resolveMetadataId` could distinguish "object genuinely absent" (skip permanently) from "transient lookup failure" (retry) — happy to follow up. ### Why are the changes needed? Fine-grained authorization can silently and persistently under-grant. A single transient metadata-id resolution miss during a role-policy reload poisons the cache for the full expiration window (default 1 hour), so a user/role that legitimately holds a grant is denied even though the grant and the target object both exist. The symptom is characteristic: authorization works immediately after a server restart (fresh policy load), then flips to `Forbidden` about one cache-TTL later and stays stuck until the next eviction. ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? Added `TestJcasbinAuthorizer.testTransientMetadataResolutionFailureDoesNotStickDenial`, which drives the real `JcasbinAuthorizer`: baseline authorize succeeds; the role is evicted and `MetadataIdConverter.getID` is stubbed to return empty for one reload (transient outage), yielding a deny; resolution then recovers. Before the fix the denial sticks (`expected: <true> but was: <false>`); after the fix authorization self-heals. The full `TestJcasbinAuthorizer` suite passes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
