Version

main branch

Describe what's wrong

dropCatalog(force=false) can incorrectly fail with NonEmptyCatalogException when the remaining schema was imported from the underlying catalog instead of being created through Gravitino.

For example, a Hive catalog may already contain the default schema. After metadata synchronization imports it into the entity store, dropCatalog(force=false) may still treat it as a user-created schema and block catalog deletion.

Error message and/or stacktrace

NonEmptyCatalogException: Catalog <metalake>.<catalog> has schemas, please drop them first or use force option

How to reproduce

1. Use main branch.
2. Create a catalog backed by an external system that already contains schemas.
3. Trigger schema import / metadata synchronization.
4. Call dropCatalog(<catalog>, false).
5. Observe that the drop is rejected even though the schema was imported from the external catalog.

Additional context

The issue is in the schema classification logic used by CatalogManager.dropCatalog(...).

A fix should:

• not treat imported schemas as user-created
• still block drop for schemas created through Gravitino
• fail conservatively when schema classification fails unexpectedly