Hi, 

I've done some research internally and found the thing that usually catches people out is that Lakeflow Connect for SQL Server isn't one pipeline, it actually has a few different components.

There's a gateway (talks to SQL Server, writes to staging) and a separate ingestion pipeline (reads staging, writes to UC). If you only destroyed the ingestion pipeline, the gateway could still sitting on the broken state.

A few things to make sure you've deleted:

- Both pipelines: destroy the gateway too, not just the ingestion side.
- SQL Server side: Lakeflow recreates its own lakeflow_* capture instances on full refresh, but a broken one can stick around. Check cdc.change_tables and EXEC sys.sp_cdc_help_change_data_capture for stale lakeflow_* rows. Disabling + re-enabling CDC on the source table usually clears it.
- UC side: destination tables drop on pipeline delete, but staging volumes hang around for 25–30 days, and any schemas the pipeline created in UC don't always go with it. Worth dropping the staging schema/volume before you recreate.

Order of operations that should work: stop + delete ingestion pipeline → stop + delete gateway → clean up SQL Server CDC on the affected tables → drop residual UC staging schemas → recreate gateway → recreate ingestion pipeline (fresh staging location if you can).

Also: open a support case. The docs say full refresh should recover from INCOMPATIBLE_SCHEMA_CHANGE and that destination tables drop on delete, if this isn't happening then our engineers should know about it. Include the original DDL diff, the failure event log, and what failed on both the refresh and the recreate.

I hope this helps.

Thanks,

Emma