Is this a new bug in dbt-core?
Current Behavior
I have a simple model that fails to create using the --empty flag in a run when there is a reference to another (simple) model and a AS statement.
Expected Behavior
Using the --empty flag in the run command should not have any impact in this case.
Steps To Reproduce
bug.sql file in models dir :
SELECT sometable.column FROM {{ref("somemodel")}} AS sometable
that depends on the somemodel.sql file in models dir :
dbt run --empty produces the following error :

I think that the problem comes from the auto generation of the underlying SQL request in the target/run directory :
create view "db"."schema_dev"."bug__dbt_tmp"
as (
SELECT sometable.column FROM (select * from "db"."schema_dev"."somemodel" where false limit 0) _dbt_limit_subq_somemodel AS sometable
);
Indeed an automatic table name is added (_dbt_limit_subq_somemodel). And as there is already a AS statement, it makes the whole request fails.
The bug is no more presen when a full run (i.e. without the --empty flag) is performed, as it creates a correct request as follow (target/run) :
create view "db"."schema_dev"."bug__dbt_tmp"
as (
SELECT sometable.column FROM "db"."schema_dev"."somemodel" AS sometable
);
Moreover, the problem is not present, with or without the --empty flag, when there is no model dependence. For example as with the following model named nobug.sql :
SELECT sometable.column FROM film AS sometable
It produces a correct request file in the target/run dir (same file generated with or without the --empty flag) :
create view "db"."schema_dev"."nobug__dbt_tmp"
as (
SELECT sometable.column FROM table AS sometable
);
Relevant log output
No response
Environment
- OS:Ubuntu 22.04
- Python:3.10.3
- dbt:1.8.5
Which database adapter are you using with dbt?
postgres
Additional Context
It seems to fail with either a ref or a source dependence.
Is this a new bug in dbt-core?
Current Behavior
I have a simple model that fails to create using the
--emptyflag in arunwhen there is a reference to another (simple) model and aASstatement.Expected Behavior
Using the
--emptyflag in the run command should not have any impact in this case.Steps To Reproduce
bug.sqlfile inmodelsdir :that depends on the
somemodel.sqlfile inmodelsdir :dbt run --emptyproduces the following error :I think that the problem comes from the auto generation of the underlying SQL request in the
target/rundirectory :Indeed an automatic table name is added (
_dbt_limit_subq_somemodel). And as there is already aASstatement, it makes the whole request fails.The bug is no more presen when a full run (i.e. without the
--emptyflag) is performed, as it creates a correct request as follow (target/run) :Moreover, the problem is not present, with or without the
--emptyflag, when there is no model dependence. For example as with the following model namednobug.sql:It produces a correct request file in the
target/rundir (same file generated with or without the--emptyflag) :Relevant log output
No response
Environment
Which database adapter are you using with dbt?
postgres
Additional Context
It seems to fail with either a
refor asourcedependence.