Open jeremyyeo opened 1 year ago
Thanks for reporting this @jeremyyeo! And thank you for the nice reprex above 🤩
Indeed, this does look similar to https://github.com/dbt-labs/dbt-core/issues/8859.
I'm going to leave this as a stand-alone issue since your example looks unique since it is triggered by a new model version (rather than a property change like in #8859).
We may consolidate these into the same issue in the future though.
We should check if this is resolved by https://github.com/dbt-labs/dbt-core/pull/8865
@dbeatty10 This appears not to be resolved. I followed the repro steps above on dbt 1.7.13 and I'm still seeing the same error.
$dbt run -m foo bar
20:00:16 Running with dbt=1.7.13
20:00:17 Registered adapter: postgres=1.7.13
20:00:17 Encountered an error:
Compilation Error
'model.my_dbt_project.bar' depends on 'model.my_dbt_project.foo' which is not in the graph!
Thanks for checking this and sharing the result @karenderer ! 🏆
There's a handful options for workarounds in the meantime -- all of which should only need to be done a single time.
dbt build --no-partial-parse
dbt clean
commanddbt clean && dbt build
partial_parse.msgpack
filerm -rf target
partial_parse.msgpack
file within the target folderrm target/partial_parse.msgpack
Thank you! Disabling partial parsing seems to do the trick for now - appreciate the fast reply!
Just wanted to chime in to say that my team is currently encountering this behaviour.
The proposed workarounds do work and implementing them in our production executions has been trivial (so many thanks about that, you saved my friday afternoon), but it's been quite unpleasant having to communicate to everyone in our dbt project about them, and will continue to be.
Looking forward to a fix that will make us free from having to remind everyone that they need to clean their target
everytime they run anything, just in case some other colleague has introduced a new version.
Is this a new bug in dbt-core?
Current Behavior
When adding a new model version (i.e.
foo_v2.sql
) - partial parsing appears to not be able to find the previous version of the model even though thefoo.sql
file exist. Things work correctly when doing a full parse (i.e.dbt clean
/ deletetarget/
folder first).Expected Behavior
Partial parsing should be able to detect the previous model file.
Steps To Reproduce
target/partial_parse.msgpack
file:foo
(new .sql file + changes to schema yml file):Relevant log output
Environment
Which database adapter are you using with dbt?
postgres
Additional Context
No response