yuqi1129 opened a new issue, #13278:
URL: https://github.com/apache/gravitino/issues/13278
### Version
main branch
### Describe what's wrong
For an external-backed schema, an explicit cascading drop leaves its
Gravitino registration behind if the schema was already removed directly in the
source. The operation returns `dropped: false`, and schema write-through
secrets remain stored.
An explicit `cascade=true` request should remove the stale registration and
its write-through secrets and report `dropped: true`. A repeated drop should
return false. Non-cascading drops should retain their current behavior of
preserving missing registrations that may represent externally renamed schemas.
### Error message and/or stacktrace
No exception is required. The drop response reports `dropped: false`, while
the schema registration remains live in the metadata store.
### How to reproduce
1. Create or import an external-backed schema through Gravitino so it has a
stored registration.
2. Remove that schema directly in the source without going through Gravitino.
3. Call `DELETE
/api/metalakes/{metalake}/catalogs/{catalog}/schemas/{schema}?cascade=true`.
4. Observe `dropped: false` and the retained schema registration. If the
registration has write-through secrets, they are retained as well.
### Additional context
`SchemaOperationDispatcher.dropSchema()` currently deletes unmanaged schema
metadata only when the connector reports a successful source deletion. A schema
that is already absent therefore cannot be explicitly cleaned up this way.
This issue concerns explicit cascading drops. General background
reconciliation is tracked separately in #12155.
--
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]
