When specifying the env var dbt_DEFER_STATE in your terminal, it appears to be considered even when you try to overrule the state manually using dbt test --defer --state mystate
The following example results in stateprod being used as state.
When doing the same with dbt_STATE (and unsetting dbt_DEFER_STATE), it works as expected, and the flag gets precedence.
I actually figured I should probably place a bug report. So did that here:
opened 10:58AM - 16 Jan 25 UTC
bug
awaiting_response
### Is this a new bug in dbt-core?
- [x] I believe this is a new bug in dbt-cor… e
- [x] I have searched the existing issues, and I could not find an existing issue for this bug
### Current Behavior
When specifying the env var DBT_DEFER_STATE=stateprod, it appears to be considered even when you try to overrule the state manually using `dbt test --defer --state state` (non-prod)
Do I miss something regarding
### Expected Behavior
Expected to be able to overwrite the state using the flags, as stated in the docs: https://docs.getdbt.com/reference/node-selection/syntax#establishing-state
### Steps To Reproduce
The following example results in `stateprod` being used as state.
<img width="374" alt="Image" src="https://github.com/user-attachments/assets/d028f307-2132-424a-acaf-28f09dc071f6" />
When doing the same with DBT_STATE (and unsetting DBT_DEFER_STATE), it works as expected, and the flag gets precedence. i.e. the used state is 'state'
<img width="366" alt="Image" src="https://github.com/user-attachments/assets/6cda0d88-607a-447e-a965-1f22d48b6965" />
### Relevant log output
```shell
NA
```
### Environment
```markdown
- OS: Windows 11
- Python: 3.10.5
- dbt: 1.8.7
```
### Which database adapter are you using with dbt?
spark
### Additional Context
I noticed that the on-run-end DOES use the expected state (provided via the cli flags) when having DBT_DEFER_STATE set! Causing inconsistent catalogs being referred in my case.
