You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dbt build is exiting earlier than it should when faced with a broken project. This leads to an inconsistent user experience, and an incomplete process artifacts (run_results.json). Work done to correct this seemed to lead into larger discussions about the expected behavior of the fail-fast flag.
dbt build is exiting earlier than it should when faced with a broken project
It seems to exit as soon as it encounters any runtime error, including SQL errors when running models—so not a broken project per se. That means its logging output looks different from all other tasks, and it never writes run_results.json. Not good!
Sometimes that "instant exit on error" is a feature, not a bug—it should only be when the -x, --fail-fast flag is passed. Incidentally, dbt build --fail-fast seems to work just fine (and differently!) when it encounters an error. (Today, --fail-fast errors for all commands prevent writing the result artifact. Is that good as a general rule? Fair question: #3600.)
What's surprising to me is how/why dbt build has different behavior from standard-issue tasks like dbt run and dbt snapshot, when I figure it inherits so much of its behavior from the base tasks.
jtcohen6
changed the title
Correct non-fast-failing behavior to match other tasks such as run
dbt build: Correct non-fast-failing behavior to match other tasks such as run
Jul 21, 2021
dbt build
is exiting earlier than it should when faced with a broken project. This leads to an inconsistent user experience, and an incomplete process artifacts (run_results.json
). Work done to correct this seemed to lead into larger discussions about the expected behavior of thefail-fast
flag.References:
build
#3490 (review)build
#3490 (review)The text was updated successfully, but these errors were encountered: