Kim
04/10/2026, 6:51 PMHere's the error:
ERROR dbt1501: Failed to render SQL undefined value
(in dbt_packages/elementary/dbt_project.yml:25:1)
(in dbt_packages/elementary/macros/edr/system/hooks/on_run_end.sql:25:29)
(in dbt_packages/elementary/macros/edr/dbt_artifacts/upload_source_freshness.sql:8:23)
(in dbt_packages/elementary/macros/edr/dbt_artifacts/upload_source_freshness.sql:33:37)
--> dbt_packages/elementary/dbt_project.yml:25:1
It started suddenly on April 8th without any significant change on our side.
Do you know if:
• Were there any recent updates to Elementary?
• This is a known issue (maybe related to Elementary)?
• Are there recommended steps to debug/fix it?
Happy to share more context if needed 🙏Jon Simpson
04/15/2026, 12:25 AMedr monitor is there a way to filter by test type, like just anomalies. DBT Cloud already alerts the other failures typesJon Simpson
04/15/2026, 5:06 PMParkash Pant
04/15/2026, 5:32 PMpre and prod environment. When I run dbt build --select dbt_models in pre, it creates new entry for each dbt model with different generated_at but in prod, it doesn't add any redundant record and only add records, if it found new model. Does anyone else experienced this? What I am doing wrong?Jose
04/16/2026, 2:52 PMTim Luca Derksen
04/17/2026, 8:12 AM0.23.1 on dbt-fabric (Microsoft Fabric Warehouse). Our dbt-fabric adapter does not yet support the merge incremental strategy, so all Elementary artifact/run-results models currently fail on my setup.
We are planning to upgrade the dbt-fabric adapter soon to a newer version, right now we aren't able to do it safely.
The only supported non-append strategy on Fabric is delete+insert. As a workaround I'm overriding Elementary's dispatched macro in my own project:
{%- macro fabric__get_default_incremental_strategy() %}
{% do return("delete+insert") %}
{% endmacro %}
Before I roll this out, I wanted to sanity-check with you whether this is safe for Elementary's data model. A few concerns I'd appreciate your input on:
1. created_at semantics — insert_rows.sql auto-assigns created_at on insert. Under merge, matched rows keep their original created_at. Under delete+insert, the row is dropped and reinserted, so created_at is overwritten on every run. Is this used anywhere by Elementary as a "first seen" timestamp, or is generated_at the canonical one?
2. Atomicity / partial failures — delete+insert is two separate statements. If the INSERT fails after the DELETE, rows are missing until the next run. Are any Elementary models (especially dbt_run_results, elementary_test_results, data_monitoring_metrics) relied upon by other models within the same invocation in a way that this transient inconsistency could break?
3. merge_update_columns / merge_exclude_columns — are any Elementary models using these? They'd be silently ignored under delete+insert.
4. Cross-table consistency — dbt_columns.parent_unique_id etc. logically reference dbt_models.unique_id. During a run, when the parent table is mid delete+insert, child tables briefly reference non-existent parents. Is that handled downstream, or does the Cloud UI / report generation assume a consistent snapshot?Dragos Cioata
04/23/2026, 8:11 AMEncountered an error while running operation: Database Error
Invalid timestamp: '2026-04-23T08:00:50.701497056Z'; while executing the filter on column 'execute_completed_at'"
name: "RunningOperationCaughtError"
I have
edr (0.23.2) and Elementary's dbt package (0.23.1) are compatible.
and dbt-bigquery==1.11.1
Is the latest bigquery adapter not compatible?Sebastian Zaffarano
05/11/2026, 9:32 AMAnh Nguyen
05/18/2026, 8:27 AMThomas Langton
05/21/2026, 3:49 PMSaket Gupta
05/27/2026, 5:22 AMPrat Agrrawal
05/29/2026, 11:02 AMZakaria Hassan
06/01/2026, 9:43 AMHudson Santos
06/02/2026, 8:48 AMYang Xu
06/02/2026, 4:47 PMPaul Wallington
06/08/2026, 3:04 PMCristián Munizaga
06/10/2026, 3:20 PMNikita Kotlyarov
06/12/2026, 9:52 AMelementary-data dbt package 0.24.0.
It defines a get_incremental_microbatch_sql macro that effectively disables batch execution, unless the require_batched_execution_for_custom_microbatch_strategy flag is explicitly set.
That was pretty unexpected to discover it by full-refreshing a couple of internet-scale datasets🤦♂️Frankie Bromage
06/15/2026, 9:36 PMFederico Franco
06/16/2026, 12:54 PMErica Bertan
06/23/2026, 5:43 PMdbt test -s 'tag:non-blocking-test tag:elementary' in one task, then edr monitor in a subsequent task to send Slack alerts.
We're seeing duplicate notifications: Airflow's failure callback fires when the dbt test task fails, and edr monitor sends its own Slack alert for the same failure. To avoid the duplication, we're trying to understand exactly what edr monitor picks up from the test results table.
Does edr monitor alert on all dbt test failures stored in the Elementary results table (including generic dbt tests), or only on tests tagged with tag:elementary?Frank Tubbing [Beequip]
07/13/2026, 7:45 AM0.25.0 of Elementary and the dbt package seems to be working fine 🎉 . We also use the edr CLI python package, but this tends to give us some trouble.
So far our setup has been that we install all dbt related dependencies in a single virtualenv. When we tried to upgrade our requirements.txt into something like:
dbt==2.0.0rc196
elementary-data==0.25.0
The issue I have is that when I call dbt --version it shows me:
dbt --version
Core:
- installed: 1.11.12
- latest: 1.11.12 - Up to date!
This is not my intended behaviour I would have liked. I was wondering what the Elementary team has in mind to work around these kind of issues? (I understand there are ways around above issue, but just wanted to have the input how the Elementary team would recommend doing it)Ryan Paul
07/14/2026, 12:47 AMRubén Laguna
08/05/2026, 12:36 PMTests with error status are not being reported- If a test fails “normally” (e.g. not_null fails on rows with null values), Elementary will report it as expected with a “fail” status. However, if there is a compilation error / any error that comes before the actual test query (“error” status in dbt-core), it will currently be missing.But the Test with error status -> github.com/dbt-labs/dbt-fusion/issues/686 -> github.com/dbt-labs/dbt-core/issues/13693 shows as completed/fixed, is this claim still true today?
Alex Stevens
08/06/2026, 11:39 PM205) locally for a while now, but I default the elementary upload hooks of for dev, and finally switched over one of our production jobs in the dbt platform to fusion and ran into a pretty big issue that seems to be a hard migration blocker: github.com/elementary-data/elementary/issues/2318
Has anyone experienced this?Tim Hiebenthal
08/07/2026, 1:08 PMdbt_run_results MERGE statement.
Anybody else sharing similar observations? Any recommended workarounds?
We already have it running in prod and CI only
I guess using the more expensive MERGE statement over more efficient delete+insert in order to ensure that the operation happens in a single run and nothing gets lost
I found github.com/elementary-data/elementary/issues/1959 online but it was closedClay Johns
08/12/2026, 9:37 PM16:27:10.775302 [debug] [Dummy-1 ]: SQL status: SUCCESS 96 in 1.107 seconds
16:27:10.782603 [debug] [Dummy-1 ]: Elementary: Measured durations for context - upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS]:
16:27:10.785511 [debug] [Dummy-1 ]: Elementary: upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS].artifacts_flatten: 0:00:00.033175 (1 runs)
16:27:10.788204 [debug] [Dummy-1 ]: Elementary: upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS].insert_rows.get_columns_in_relation: 0:00:00.090482 (1 runs)
16:27:10.790742 [debug] [Dummy-1 ]: Elementary: upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS].insert_rows.get_insert_rows_queries.base_query_calc: 0:00:00.008085 (1 runs)
16:27:10.793319 [debug] [Dummy-1 ]: Elementary: upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS].insert_rows.get_insert_rows_queries.render_row_to_sql: 0:00:01.577595 (96 runs)
16:27:10.795835 [debug] [Dummy-1 ]: Elementary: upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS].insert_rows.get_insert_rows_queries: 0:00:01.633232 (1 runs)
16:27:10.798535 [debug] [Dummy-1 ]: Elementary: upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS].insert_rows.run_insert_rows_query: 0:00:01.131391 (1 runs)
16:27:10.801206 [debug] [Dummy-1 ]: Elementary: upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS].insert_rows.commit: 0:00:00.001003 (1 runs)
16:27:10.803650 [debug] [Dummy-1 ]: Elementary: upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS].insert_rows: 0:00:02.863358 (1 runs)
16:27:10.806335 [debug] [Dummy-1 ]: Elementary: upload_artifacts_to_table[DBT_SOURCE_FRESHNESS_RESULTS]: 0:00:02.900628 (1 runs)
16:27:10.823213 [debug] [Dummy-1 ]: Elementary: Uploading dbt invocation.
16:27:10.902747 [debug] [Dummy-1 ]: Using snowflake connection "master"
But there aren't any rows in the table DBT_SOURCE_FRESHNESS_RESULTS
Any idea what I am doing wrong?
command - source freshness --target prod
Excerpts from the dbt_project.yml:
flags:
source_freshness_run_project_hooks: true
models:
elementary:
+schema: 'ELEMENTARY'
+full_refresh: "{{ var('elementary_full_refresh', false) }}"
disable_dbt_artifacts_autoupload: "{{ target.name == 'dev' }}"
disable_run_results: false
disable_tests_results: false
disable_dbt_invocation_autoupload: false
elementary_full_refresh: falseDaniel Wiszowaty
09/15/2026, 1:25 PM--v2 parser for dbt, but this blocks us because we rely on Elementary package loveMariah Rogers
09/21/2026, 6:15 PMOliver Tosky
09/25/2026, 5:39 PMelementary-data==0.26.0