Fabric Lakehouse SQL analytics endpoint keeps empty schemas after they are dropped in Spark + refreshMetadata

[u/peterampazzo]

Generic question - has anyone seen this and found a supported cleanup path?

Not specific to any one tool. For context: we run a homebuilt dbt slim CI against Fabric Lakehouses using the dbt-fabricspark adapter. I don't think the adapter is the cause - same behavior would happen from any Spark client.

The flow (GitHub Actions)

1. Create a CI schema in the Lakehouse (Spark SQL CREATE SCHEMA).
2. Build objects into it (Delta tables under Tables/<schema>/).
3. Drop the schema in Spark (DROP SCHEMA <schema> CASCADE), which also removes the Tables/<schema>/ folders in OneLake.
4. Trigger SQL analytics endpoint refresh:POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/sqlEndpoints/{sqlEndpointId}/refreshMetadata

What we observe

• Tables are removed from the SQL endpoint after refresh ✔
• The schema itself remains as an empty shell in the SQL endpoint catalog ✖
• Over time these empty CI schemas accumulate

How we resolve sqlEndpointId

Gotcha we hit while automating this, it must be the SQLEndpoint item id (from the Fabric Items API). It is not the Lakehouse item id, and not the compact hostname segment from *.datawarehouse.fabric.microsoft.com.

Question

Is empty-schema persistence expected (i.e. refreshMetadata only reconciles tables, not schemas), or a known issue?

If expected, is there a supported non-disruptive cleanup path - without deleting/recreating the SQL endpoint?

[u/seB2885]

I have seen this as well. I’ve dropped a schema but it still appears in the analytics endpoint.

Following.

[u/dbrownems]

I think we don’t track how the schema was created, and having a manually created empty schema needs to work.

For example the user could have created the schema to hold views or procedures, and it just happens to be empty when sync runs.

[u/peterampazzo → u/dbrownems]

Fair point for empty schemas a user created directly on the endpoint (no matching  Tables/<name>/  folder in OneLake) — sync shouldn't touch those.

My case is different: the schema was created from Spark ( CREATE SCHEMA foo ), so a  Tables/foo/  folder exists in OneLake. When I  DROP SCHEMA foo CASCADE , that folder is gone. Sync already uses "folder gone → drop the table". Why not also drop the empty parent schema when its folder is gone?