mchades opened a new issue, #14119:
URL: https://github.com/apache/gravitino/issues/14119
### Version
main branch
### Describe what's wrong
For a fileset catalog, `CatalogManager.dropCatalog(..., true)` calls
`FilesetCatalogOperations.dropSchema(..., true)` directly. This path deletes
the
schema and fileset metadata before removing managed storage, and only logs a
warning if a fileset location cannot be deleted. The fileset's metadata is
lost
even though its data remains, preventing a normal retry. Force-dropping the
parent
metalake reaches the same path.
The failed fileset and its parent metadata should remain available for retry.
Filesets already deleted successfully need not be restored.
### Error message and/or stacktrace
Storage cleanup logs `Failed to delete fileset ... location: ...`, but the
fileset
metadata has already been removed.
### How to reproduce
1. Create a fileset catalog, a schema, and a managed fileset.
2. Make deletion of the fileset's storage location fail while leaving
metadata
access available.
3. Delete the catalog with `force=true`.
4. Observe that the failed fileset's metadata is removed although its storage
location remains.
A regression test also reproduces this through the catalog's schema
operations
with `FileSystem.delete()` returning `false` or throwing `IOException`.
### Additional context
Direct fileset deletion already preserves metadata on storage cleanup
failure.
The normal schema dispatcher also deletes filesets before deleting the
schema;
catalog force-drop bypasses that dispatcher.
--
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]
