Hi Dmitri,
I looked into the history, to try find if there was some commit I can
point to or grab some context
Was there a use case? No evidence of one. Both the cleanup=true and
the // cleanup grants comment arrived with the initial code import
(88fbb9ae77, "Merge Polaris catalog code (#1)", 2024-07-25), not as a
later deliberate choice. And in that same commit, the handler already
rejected anything but a table:
return task.getTaskType() == AsyncTaskType.ENTITY_CLEANUP_SCHEDULER
&& taskEntityIsTable(task);
private boolean taskEntityIsTable(TaskEntity task) {
PolarisEntity entity =
PolarisEntity.of((task.readData(PolarisBaseEntity.class)));
return entity.getType().equals(PolarisEntityType.TABLE_LIKE);
}
So a role-payload task has never been handleable, not even briefly —
this isn't a capability that regressed. I also checked whether a
sibling handler for other entity types ever existed and was removed:
git log --diff-filter=D over the task package returns nothing, and the
only commits touching ENTITY_CLEANUP_SCHEDULER are the
metadata/statistics cleanup work and the recent task-name fix. Neither
delete path reads getCleanupTaskId() either, so the task was never
dispatched.
Were they meant to delete dangling grant records? That seems to be
what the comment's author believed, but grant removal has never
depended on the flag, and I don't think dangling records are
reachable:
- On the atomic/JDBC path, dropEntity deletes grants in both
directions unconditionally, before the flag is ever consulted. The
JDBC predicate is a single statement covering grantee and securable:
WHERE ((grantee_id = ? AND grantee_catalog_id = ?) OR (securable_id =
? AND securable_catalog_id = ?)) AND realm_id = ?.
- On NoSQL, the records outlive dropEntity but are reclaimed by
persistence maintenance, which is the documented design —
TestCatalogMaintenance asserts exactly that: the grant ACL heads
survive the drop, loadGrantsOnSecurable already returns empty, and a
maintenance run drives the count to zero.
So both backends already have an answer, one synchronous and one
deferred to maintenance. I couldn't find a state where a grant record
outlives its role with nothing to clean it up.
-Ayush
On Wed, 7 Oct 2026 at 05:01, Dmitri Bourlatchkov <[email protected]> wrote:
>
> Hi All,
>
> As discovered in PR [5686] role deletion used to persist task records
> apparently aim to "cleanup grants" (see PR diff for details). However, such
> tasks cannot be handled by Polaris ATM.
>
> Is there a use case for these cleanup tasks?
>
> Were they supposed to delete dangling grant records pointing to deleted
> roles?
>
> Is there interest in the community to implement that cleanup behaviour?
>
> [5686] https://github.com/apache/polaris/pull/5686
>
> Thanks,
> Dmitri.
