@kapa.ai We've recently started experimenting with

dbt state

(State adapter: dbt-state v2.29.3 is enabled) while running

dbt core 1.12

Elementary 0.25

and

edr cli 0.25.0

After implementing

dbt state

we've experience problems with alerts not being sent. When the alerts_v2 tables is dropped and we run

edr monitor

it will send the alerts, but will fail to sent alerts the following run. Can you suggest a solution?

The knowledge sources do not explicitly mention specific interactions or known bugs between Elementary and

dbt state

(or

dbt-state

adapters). However, the behavior you are describing—alerts sending once after dropping

alerts_v2

but failing on subsequent runs—is directly tied to how Elementary manages alert state and deduplication. Why this happens Elementary's alert tables (such as

alerts_v2

) are incremental tables used to maintain state [alerts incremental]. When

edr monitor

runs: 1. It queries pending alerts and sends them to your destination. 2. It updates those alerts to

sent

or

skipped

with a timestamp [Slack alerts once]. 3. On the next run, if there are no new test failures/invocations recorded in

elementary_test_results

, Elementary treats the previous failures as duplicates or already-sent and marks them as skipped rather than resending them [Skip duplicate alerts; Why monitor not sending]. Dropping

alerts_v2

wipes this history, which is why dropping it temporarily resets the state and sends alerts again [alerts state issue]. When introducing

dbt state

(e.g., using

state:modified

), your dbt commands may be skipping tests or failing to log new invocation results to Elementary's metadata tables, leading

edr monitor

to find no new alerts. Suggested Solutions & Troubleshooting Steps 1. Check If New Test Results Are Being Recorded Elementary requires each test run to write fresh results into the Elementary schema before

edr monitor

is executed [Data flow to alerts]. • Verify that

elementary_test_results

has new records generated for the failing tests on your subsequent

dbt test

/

dbt build

runs. • If you are running

dbt test --select state:modified

(or similar state-based selectors), tests that did not change may not be re-evaluated, meaning no new failure records are produced. 2. Verify Execution Order Ensure your pipeline follows the proper execution sequence for every run [Quickstart note]: 1.

dbt run

/

dbt test

(creates fresh records in

elementary_test_results

) 2.

edr monitor

(processes new records from the latest invocation and updates

alerts_v2

) If

edr monitor

is executed repeatedly against the exact same dbt invocation results, it will intentionally skip them [Why monitor not sending]. 3. Ensure Elementary Models Are Materialized Correctly Check your

dbt_project.yml

to ensure that global model configurations have not altered the materialization of Elementary models. For instance, setting a project-wide default such as:

models:
  +materialized: table

can cause internal Elementary models (like

alerts_v2

/

alerts_dbt_tests

) to fail to refresh incrementally or update correctly during runs [Materialized table issue; similar fix]. Scope any global materializations away from the

elementary

package. 4. Rebuild Elementary Models If the state of the tables was corrupted or altered during your

dbt state

transition, rebuild the Elementary models cleanly [Quickstart note]:

dbt run -s elementary

Then run your

dbt test

and

edr monitor

commands. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai In the end, I ended up updating the

elementary

profile in

profiles.yml

with the following key-value pair:

run_cache_cache_mode: WRITE_ONLY

This seems so have fixed the problem for now

The knowledge sources do not explicitly mention or document the

run_cache_cache_mode: WRITE_ONLY

profile configuration or its specific interaction with Elementary and

dbt-state

. However, thank you for sharing this solution! It makes sense in the context of state caching: when state or caching mechanisms intercept or read stale cache data during

edr monitor

operations, Elementary might fail to detect updated records or properly evaluate new pending alert queries. Setting the cache mode to write-only likely ensures that dbt/Elementary operations bypass cached read states and directly fetch the latest records from your warehouse. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.