dbt-snowflake: snowflake__create_or_replace_view() is using default__handle_existing_table()

[ryanlattanzi]

Hello,

We recently had an incident where we had a source table (PROD.PUBLIC.MY_TABLE) already in existence, and we created a model materialized as a view that accidentally had the same name in the same schema. This resulted in our PROD.PUBLIC.MY_TABLE production table being dropped. Note that we DID NOT pass the --full-refresh flag. However, in the logs we saw drop table if exists "PROD"."PUBLIC"."MY_TABLE" cascade.

Looking through the dbt-snowflake source code for the view materialization, we came across this comment. It seems to explain our exact situation. But the comment says "If there's a table with the same name and we weren't told to full refresh, that's an error.".

But, we didn't pass --full-refresh, and yet no error was thrown. Instead, the existing prod table was dropped.

We think that the dispatcher handle_existing_table tries to find an adapter implementation (e.g. snowflake__handle_existing_table as seen in the bigquery adapter), but otherwise falls back to default__handle_existing_table.

However, we noticed that default__handle_existing_table does not take into account the full_refresh argument, which explains why DBT decided to drop our production table.

Hopefully that context was decent. Our question is - is this intentional? If so, why? Why does BigQuery have the safeguard but not Snowflake? BigQuery's safeguard seems like the logical way to handle this situation.

This incident happened to drop an extremely critical table that we were able to recover with Snowflake's Time Travel feature (🙏 🙏 ), but it seems very buggy and unsafe.