Hi team, hope you are well. Through my exploration, I've come to understand that the tables

alerts_models

,

alerts

and

alerts_source_freshness

are configured incrementally in the elementary package. Is my understanding correct? If so, what could be the potential reasons for these tables being dropped and recreated? I've observed that in our Snowflake instance, the tables get recreated each time there is an update.

Hey @An, if the relations are dropped and recreated, there might be some alerts that are resent, as these tables are used to keep state as to which alerts have already been sent. When exactly are they dropped and recreated? I did not exactly understand what you meant by "update" (insertions to the table? update to the dbt version? the snowflake version?)

Hi @Ofek Weiss, thanks for the reply. Yes, receiving alerts that we have already received is exactly what I’m trying to solve. Through my investigation, I discovered that dropping and recreating the table caused the issue. By "dropped and recreated," I mean the entire table, because I observed that the creation date of the table corresponds to the time of the recent run, and the past alerts that have been marked as 'sent' become 'pending'.

The adapters get_relation logic should be unrelated, seems that for some reason your alert tables are not updated incrementally, but are recreated from scratch every time. I'd like to understand more about your pipeline, what are the commands that you are running exactly?

Oh, got it. Thanks for clarifying. I'm going to send you the log in private chat