Repository navigation
[BUG] Catalog and schema deletion destroys tables when force=false #32
Description
Description
Both deletion endpoints ignore the force query parameter and unconditionally cascade through nonempty catalogs/schemas.
Reproduced on MiniLake 1.9.0, commit fe8837dcfac9df621dfabc440abc07ebb4cdbcbb, using the repository's Docker test image, a real HTTP server, and fresh disposable state. Image Python sources were verified byte-for-byte against this commit. No mocks or production data were used.
Affected Components
- src/minilake/services/unity_catalog.py —
delete_catalog - src/minilake/services/unity_catalog.py —
delete_schema - src/minilake/duckdb_pool.py —
detach_catalog
Steps to Reproduce
Use a disposable instance and data directory. Paths below are relative to its HTTP base URL; bodies are JSON unless explicitly described as raw bytes. IDs shown as W/J/R/Q/C/HANDLE are replaced with the IDs returned by prior calls.
- Create a warehouse (
POST /api/2.0/sql/warehouses,{"name":"audit","cluster_size":"Small"}) and catalog (POST /api/2.1/unity-catalog/catalogs,{"name":"force_schema"}). - Execute
CREATE TABLE force_schema."default".precious AS SELECT 42 AS idthrough/api/2.0/sql/statementswith that warehouse ID. DELETE /api/2.1/unity-catalog/schemas/force_schema.default?force=false.- Execute
SELECT * FROM force_schema."default".precious. - Repeat with a fresh catalog
force_catalogandDELETE /api/2.1/unity-catalog/catalogs/force_catalog?force=false. Omission offorcetakes the same code path.
Expected Behavior
Nonempty deletion is rejected unless the caller explicitly supplies force=true; all data remains intact after rejection.
Actual Behavior
Both DELETE calls return 200. The schema path executes DROP SCHEMA CASCADE; the catalog path removes the catalog database file. Subsequent SELECTs fail because the data is gone.
Root Cause Analysis
Neither handler declares or checks force. delete_schema always uses CASCADE; delete_catalog always calls detach_catalog, which unlinks the database and WAL.
Impact
Ordinary SDK/Terraform cleanup code can irreversibly delete local tables despite explicitly disabling forced deletion. It also validates destructive workflows that should fail on Databricks.
Severity is assessed within MiniLake's documented local development/CI use; it does not assume a shared production Databricks deployment.
Suggested Fix
Accept and validate force, check both registered and physical children before mutating anything, reject nonempty deletion by default, and cascade only for explicit force.
Test Coverage Gaps
Catalog/schema tests exercise deletion but do not verify preservation of a populated table when force is absent/false. Cover both flags, SQL-created tables, volumes and functions.
Severity
High
Confidence
High — reproduced through the real HTTP API and traced to the source paths above.
Recommended Labels
bug, high-priority
Existing Issue Matches
No reasonable duplicate found. Reviewed all open and closed issues and open pull requests in dmux/minilake, then searched component/function/symptom terms for this finding. The only open PR at review time, #29, changes the virtualenv lock entry and does not address this defect. The documented intentional limitations were checked before reporting.
API Reference
Catalog delete contract and schema delete contract document force as the nonempty-deletion override.
Activity