LuciferYang opened a new issue, #13522: URL: https://github.com/apache/gravitino/issues/13522
### Version main branch ### Describe what's wrong The metalake cascade drop tombstones the role rows and tag rows before the securable-object and tag-relation cleanups run, in the same transaction. Those cleanups filter the parent join on the parent's `deleted_at = 0`. Because a transaction sees its own writes, the `EXISTS` matches no live parent row, the `UPDATE` affects zero rows, and the `securable_object` and `tag_relation_meta` rows stay live forever with no remaining cleanup path (the legacy hard delete only removes already-tombstoned rows). ### Error message and/or stacktrace No exception. After a cascade drop of a metalake that owns roles-with-securable-objects or tag assignments, orphaned live rows remain in `securable_object` and `tag_relation_meta` (incorrect persisted state and storage leak). ### How to reproduce Create a metalake with a role that has securable objects (or a tag assigned to an object), then `dropMetalake(ident, cascade=true)`. The securable-object / tag-relation rows remain with `deleted_at = 0`. ### Additional context Dropping the parent-side `deleted_at` filter from both cascade statements fixes it; the join key already scopes membership to the metalake, and the sibling PolicyTagRel cascade already uses this order-safe shape. -- 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]
