nevzheng opened a new issue, #14268:
URL: https://github.com/apache/gravitino/issues/14268
### Version
main branch
### Describe what's wrong
`AuthorizationUtils.removeCatalogPrivileges` calls
`authorizationPlugin.onMetadataUpdated(MetadataObjectChange.remove(...))`
and discards the `Boolean`
result. `onMetadataUpdated` documents `false` as failure, and
`ChainedAuthorizationPlugin` passes a
sub-plugin's `false` through.
`CatalogHookDispatcher#dropCatalog` then calls
`dispatcher.dropCatalog(ident, force)` regardless. So when
the plugin cannot remove the catalog's privileges (for example Ranger is
unreachable or returns an
error), the catalog is deleted anyway and its privileges stay in the plugin.
A later catalog with the
same name picks them up, and nothing retries the removal, because the
catalog no longer exists in
Gravitino.
### Error message and/or stacktrace
None. The drop returns `true`.
### How to reproduce
1. Create catalog `c` with an `authorization-provider` whose plugin returns
`false` from
`onMetadataUpdated` for the catalog removal (for example a Ranger plugin
that fails to update its
policies).
2. `DELETE /api/metalakes/m/catalogs/c?force=true`.
Expected: the drop fails with an error naming `c`, and `c` remains so the
drop can be retried.
Actual: `c` is deleted and its privileges remain in the plugin.
### Additional context
Proposed fix: treat any result other than `true` as failure in
`removeCatalogPrivileges` and throw
`AuthorizationPluginException` naming the catalog, before the catalog is
dropped.
--
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]
