## TL;DR
dbt builds the new table under a temp name and swaps it into place, so a swap failure means the build succeeded but the rename was refused: usually missing permissions, a lock on the target table, or a leftover temp table from a crashed run. Check the exact swap error, clear the blocker, and re-run. The data is built; only the rename failed.

```text
snowflake table swap failed during dbt run
```

## Use this when
- A dbt model on Snowflake fails with a swap error.
- The temp table exists but the target was not replaced.
- It follows a crashed or killed dbt run.

## Not for this skill when
- The model build itself failed. Fix the build first.
- You swap tables manually outside dbt. Check your own swap script.

## Steps
1. Read the dbt error for the swap statement and Snowflake's refusal reason. Note the exact error. Verify: the refusal is named
2. Check permissions: the dbt role needs ownership or the right grants on both tables. Note the grants. Verify: permissions are verified
3. Look for locks on the target table from concurrent queries or another dbt run. Note the locker. Verify: locks are found or ruled out
4. Drop leftover temp tables from crashed runs that collide with the new temp name. Note the namespace is clean. Verify: orphans are cleared
5. Re-run the model and confirm the swap completes. Note the target table is fresh. Verify: the swap succeeds

## Variant phrasings
### dbt snowflake swap table permission
The grants-shaped search.
### snowflake alter table swap failed
The SQL-shaped phrasing.

Compatibility: dbt Core with the Snowflake adapter. Swap is used by table and incremental materializations.

## Why it happens
The swap pattern exists so readers never see a half-built table: build privately, then atomically rename. The rename is a metadata operation that needs ownership-level rights and an unlocked target, which makes it the step where permission and concurrency problems surface even though the heavy work already succeeded. A crashed run leaves the temp table behind, and the next run's temp name can collide with it, failing the swap before it starts.

## Edge cases / pitfalls
- Swapping does not move grants automatically in all cases. Verify grants on the new table after the swap.
- Concurrent BI queries hold locks that block the swap. Schedule swaps outside peak query windows or use short lock timeouts.
- Cloned or shared tables have ownership subtleties. Confirm the dbt role owns what it swaps.
- A swap that half-completes (rare) can leave the temp and target swapped unexpectedly. Verify table contents, not just names.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_f0ObUsZq2lXZUPEkqhiw4g