Adapter
dbt-fabric (Microsoft Fabric Warehouse); the same code path affects dbt-sqlserver.
Summary
On T-SQL/Fabric the test materialization creates per-test helper tables via SELECT … INTO in the elementary package schema (to work around the "CTE inside a subquery" limitation). Two of these are never cleaned up, so they accumulate — one or more per test, per run.
Root cause 1 — test-result temp table not registered
create_test_result_temp_table (macros/edr/materializations/test/test.sql) discards the relation returned by create_temp_table, so it is never added to the temp_test_table_relations_map cache. clean_current_invocation_test_tables (on-run-end) only drops relations found in that cache, so these tables leak.
A fix was attempted in #1008, but that PR was closed unmerged.
Root cause 2 — failed_row_count temp table not registered
fabric__get_failed_row_count_calc_query (macros/edr/materializations/test/failed_row_count.sql):
{% set tmp_relation = elementary.edr_make_temp_relation(model) %}
{% do run_query("select * into " ~ tmp_relation ~ " from (" ~ sql ~ ") as __edr_inner") %}The comment states "The temp table is session-scoped and cleaned up by on_run_end", but the relation is never registered and never dropped. It leaves <test_alias>__tmp_<ts> tables (e.g. accepted_values_<model>_<hash>__tmp_<ts>). Triggered for failed tests when calculate_failed_count (default true) and a failed_row_count_calc is configured.
Note: cleanup_stale_test_tables uses the pattern test%__tmp_%, which does not match these aliases either.
Expected
Both temp relations are registered in temp_test_table_relations_map (or dropped explicitly) so the on-run-end cleanup removes them.
Repro
Run dbt tests on Fabric with the elementary test materialization enabled, then inspect the elementary schema after the run.
Adapter
dbt-fabric (Microsoft Fabric Warehouse); the same code path affects dbt-sqlserver.
Summary
On T-SQL/Fabric the test materialization creates per-test helper tables via
SELECT … INTOin the elementary package schema (to work around the "CTE inside a subquery" limitation). Two of these are never cleaned up, so they accumulate — one or more per test, per run.Root cause 1 — test-result temp table not registered
create_test_result_temp_table(macros/edr/materializations/test/test.sql) discards the relation returned bycreate_temp_table, so it is never added to thetemp_test_table_relations_mapcache.clean_current_invocation_test_tables(on-run-end) only drops relations found in that cache, so these tables leak.A fix was attempted in #1008, but that PR was closed unmerged.
Root cause 2 — failed_row_count temp table not registered
fabric__get_failed_row_count_calc_query(macros/edr/materializations/test/failed_row_count.sql):The comment states "The temp table is session-scoped and cleaned up by on_run_end", but the relation is never registered and never dropped. It leaves
<test_alias>__tmp_<ts>tables (e.g.accepted_values_<model>_<hash>__tmp_<ts>). Triggered for failed tests whencalculate_failed_count(default true) and afailed_row_count_calcis configured.Note:
cleanup_stale_test_tablesuses the patterntest%__tmp_%, which does not match these aliases either.Expected
Both temp relations are registered in
temp_test_table_relations_map(or dropped explicitly) so the on-run-end cleanup removes them.Repro
Run dbt tests on Fabric with the elementary test materialization enabled, then inspect the elementary schema after the run.