This looks like a Redshift‑specific issue with how Elementary/dbt are creating temporary relations, but the exact “`Relation ... already exists`” error pattern on

volume_anomalies

in Redshift is not explicitly documented in the knowledge sources, so I can only infer likely causes. From similar Redshift issues: - Elementary’s Redshift support has had a few warehouse‑specific bugs (e.g., connector limitations, invalid casts, name‑length limits, etc.), which required package changes or warehouse‑specific macros to fix. [[Redshift thread](https://elementary-community.slack.com/archives/C08HW57FGN9/p1764339093392769?thread_ts=1764339093.392769&cid=C08HW57FGN9); [Redshift bug](https://github.com/elementary-data/elementary/issues/1540)] - In one Redshift case, the fix was to override a macro in your own project so that Elementary generated multiple separate statements instead of a single multi‑statement query, because the Redshift connector could not handle the original pattern. [[Redshift thread](https://elementary-community.slack.com/archives/C08HW57FGN9/p1764339093392769?thread_ts=1764339093.392769&cid=C08HW57FGN9)] Given your symptoms: - The failing relation name (

prod_s3_salesforce_bronze_prod_account_6469f73e074a1

) looks like a transient/temporary table Elementary (or dbt) is creating for the test. - The suffix changes (

_xxxxxx

) and failures happen at different times, which suggests a race condition or cleanup issue: a temp relation from a previous run (or concurrent run) is still present when a new run tries to create it again. What you can do next (within what’s supported in the docs/threads): 1. Confirm it’s Elementary’s temp table - Check your Redshift schema for tables matching

prod_s3_salesforce_bronze_prod_account_%

and see when they’re created and whether they’re being dropped between runs. 2. Check for concurrent runs - If you’re running

dbt test

(or CI) with concurrency > 1, multiple

volume_anomalies

tests on the same source could be trying to create the same temp relation at the same time, leading to “already exists”. 3. Verify package/dbt versions and known Redshift bugs - There are known open Redshift issues around anomaly tests (e.g., casting booleans, connector behavior). [[Redshift bug](https://github.com/elementary-data/elementary/issues/1540)] - If you’re on an older

dbt-data-reliability

/ Elementary dbt package, upgrading may pull in Redshift fixes similar to the macro override that was needed for other Redshift errors. [[Redshift thread](https://elementary-community.slack.com/archives/C08HW57FGN9/p1764339093392769?thread_ts=1764339093.392769&cid=C08HW57FGN9)] 4. Open an issue with full details - The Elementary team explicitly encourages opening GitHub issues for Redshift‑specific anomalies, and they’ve shipped fixes after such reports. [[Issue link shared](https://elementary-community.slack.com/archives/C08HW57FGN9/p1764339093392769?thread_ts=1764339093.392769&cid=C08HW57FGN9)] - Include: - Your Elementary dbt package version - dbt version - Redshift version - The exact test config (you’ve shared it) - Whether tests are running concurrently - A sample of the compiled SQL for this test (from

target/compiled/...

) Because the knowledge sources don’t show this exact error string, I can’t point to a confirmed root cause or a specific macro to override, but the pattern strongly suggests a Redshift‑specific temp‑table naming/cleanup or concurrency bug in the current package, and the next concrete step is to surface it as a Redshift issue to the Elementary team with the compiled SQL and environment details.

Thanks for the extra details — they help narrow this down, but the knowledge sources don’t describe this exact

volume_anomalies

+ Redshift + “Relation ... already exists” pattern, so I can’t point to a confirmed root cause. I can only infer from similar Elementary/Redshift behaviors. From related issues and threads, there are a few recurring Redshift‑specific themes: 1. Temp / staging tables and cleanup Elementary’s anomaly tests create per‑test temp/staging tables (with long, generated names) and then merge their results into core tables like

data_monitoring_metrics

and

elementary_test_results

, after which the temp tables are dropped. [[Volume anomalies internals](https://elementary-community.slack.com/archives/C02CTC89LAX/p1687786556886149?thread_ts=1687786556.886149&cid=C02CTC89LAX)] There are also known cases where temporary/test tables are not cleaned up correctly or conflict with existing objects (e.g., Databricks temp views, Athena temp tables, Redshift name limits). [[Temp tables cleanup](https://elementary-community.slack.com/archives/C02CTC89LAX/p1702682903247439?thread_ts=1702682903.247439&cid=C02CTC89LAX); [Name length issue](https://github.com/elementary-data/elementary/issues/1498)] 2. Redshift‑specific adapter/connector quirks - Some Redshift issues required custom macros or changes to how Elementary generates SQL (e.g., splitting multi‑statement queries, special handling for

delete_and_insert

operations). [[Redshift macro override](https://elementary-community.slack.com/archives/C08HW57FGN9/p1764339093392769?thread_ts=1764339093.392769&cid=C08HW57FGN9)] - There are also open Redshift bugs around temp tables disappearing when connections drop and other instability around temp relations. [[Temp table loss](https://github.com/elementary-data/elementary/issues/1550)] Given your clarifications: - No concurrency, only one

volume_anomalies

test on this source. - No persistent table with that exact name exists when you check. - Other tables in the same source, with the same test config, pass. - Only

account

fails, with a changing suffix. That strongly suggests: - Elementary/dbt is generating a per‑test staging relation for this specific source table (

prod_s3_salesforce_bronze_prod_account_...

) and, for some reason, Redshift thinks it already exists at the moment the test runs, even though it’s later dropped (or is scoped in a way you don’t see it easily). - The fact that only

account

fails points to something specific to that source (schema, size, permissions, or name length) interacting badly with the Redshift adapter or Elementary’s temp‑table logic, rather than a general configuration issue. However, the knowledge sources don’t show: - Any documented bug where a single

volume_anomalies

test on Redshift repeatedly fails with “Relation ... already exists” while others pass. - A known workaround (e.g., a specific macro override) for this exact error. Because of that, I can’t give you a precise fix from the docs/threads. ### Concrete next steps (based on what is documented) 1. Capture the compiled SQL for this failing test - From

target/compiled/...

, locate the SQL for

elementary_source_volume_anomalies_s3_salesforce_account_day__3__True__day_of_week__day__1__createddate__week__2

. - This is exactly what the Elementary team asks for when debugging Redshift issues, because the problem is often in how the temp/staging relations are created. [[Redshift debugging pattern](https://elementary-community.slack.com/archives/C08HW57FGN9/p1764339093392769?thread_ts=1764339093.392769&cid=C08HW57FGN9)] 2. Check your Elementary dbt package version - Several Redshift issues have been fixed via package updates or new macros. [[Redshift fixes](https://elementary-community.slack.com/archives/C08HW57FGN9/p1764339093392769?thread_ts=1764339093.392769&cid=C08HW57FGN9)] - If you’re on an older version, upgrading may pull in improvements around temp tables and Redshift behavior. 3. Open a GitHub issue with full context The Redshift‑specific problems in the knowledge sources were resolved only after users opened issues with logs and compiled SQL. [[Issue creation link](https://elementary-community.slack.com/archives/C08HW57FGN9/p1764339093392769?thread_ts=1764339093.392769&cid=C08HW57FGN9)] Include: - Elementary dbt package version - dbt version - Redshift version - The exact test config (what you shared) - The full error message - The compiled SQL for this test - Any differences you know between

account

and the other passing tables (e.g., size, schema, special columns) Given the current knowledge, the most accurate statement I can make is: this appears to be a Redshift‑specific bug in how Elementary/dbt create or clean up the per‑test relation for this particular source, not a misconfiguration of your

volume_anomalies

test, and it needs a targeted fix from the Elementary team once they see the compiled SQL and environment details.