yuqi1129 opened a new issue, #12155: URL: https://github.com/apache/gravitino/issues/12155
### Describe the subtask A Gravitino store row can outlive its external object — after a swallowed/failed `store.delete` (`TableOperationDispatcher.dropTable` ignores `NoSuchEntityException`), a crash between the external op and the store write, or an out-of-band drop in Hive/JDBC. Today such stale rows are only repaired lazily on the next read, and actively removed only for schemas (`OrphanedSchemaCleanup`). There is no general active cleanup. Pre-existing gap, independent of the TreeLock work. ### How to fix Generalize the existing `OrphanedSchemaCleanup` / `SchemaEntityCleaner` pattern (external-existence probe -> delete orphaned store rows) from schemas to table/fileset/topic/model. Reuse `deleteTable`'s cascade so relations are removed with the row. Guardrails (an external probe is slow and can flap): - External-backed catalogs only — never managed catalogs, whose store is authoritative. - Delete only after **N consecutive misses + a grace period**, to survive transient external outages. - Rate-limit and run on a low-priority schedule (the `RelationalGarbageCollector` cadence fits). - Tests: a stale row with the external object gone is reconciled; a transient external outage does **not** delete a live row. ### Parent issue https://github.com/apache/gravitino/issues/10238 -- 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]
