Per BLG--
We'd like to take a quick step back and discuss the utility/future of pre and post hooks. @jtcohen6 can you and @aranke get together and discuss?

@iknox-fa @aranke The context for this issue was a behavior change in v1.4, around whether a failing on-run-start hook would cause the rest of the invocation to skip. For that full context, see the conversation in:

• [CT-2179] [Bug] Failing on-run-start does not stop dbt run #7045

We discussed that issue at some length during a live BLG back in March (thanks @dbeatty10 @MichelleArk @emmyoop for weighing in!), and I opened the present issue (#7387) to capture the proposal. So - I have fairly high confidence in what's being proposed in this issue, as a way of providing the advantages of both the previous (pre-1.4) + the current (1.4+) behavior. If you have specific product/UX concerns, let's find time to chat!

While the previous behavior was never explicitly documented, it's important for reenabling patterns like the one described in this article:

• https://discourse.getdbt.com/t/prevent-user-to-run-the-whole-project/9213/7

@jtcohen6 Is this just for on-run-start and on-run-end? Or do we want the same behavior for pre-hooks and post-hooks?

@jtcohen6 Would you also be able to add an acceptance criteria to the ticket?

@graciegoheen

• just on-run-start / on-run-end hooks
• updated the description to more clearly state acceptance criteria

This may already be how this works.

We aren't (Peter/Michelle) sure whether it already works like this or not. Another question is what a failure in the on-run-end hook would look like. Would it result in a fail-fast exception, or some other exception we aren't currently handling? So there is some investigation and experimentation to be done as part of the work here.

This issue reflects that, since v1.4:

• dbt has gracefully handled failures in on-run-end hooks — we still write run_results.json, which is good! There might be no changed needed here.
• dbt no longer stops runs due to a failure in an on-run-start hook — we don't skip subsequent models. This issue is not fixed in recent versions of dbt-core.

Repro case: Make a project with some models, and add this to the project file:

# dbt_project.yml

on-run-start:
  - "select askdjf"

The expected behavior is that, if an on-run-start hook fails, the rest of the models for that invocation will not run. That is not the case:

$ dbt run
07:40:37  Running with dbt=1.7.0-b1
07:40:37  Registered adapter: postgres=1.7.0-b1
07:40:37  Unable to do partial parsing because of a version mismatch
07:40:37  Found 2 models, 1 operation, 0 sources, 0 exposures, 0 metrics, 353 macros, 0 groups, 0 semantic models
07:40:37
07:40:38
07:40:38  Running 1 on-run-start hook
07:40:38  1 of 1 START hook: my_dbt_project.on-run-start.0 ............................... [RUN]
07:40:38  Database error while running on-run-start
07:40:38  Concurrency: 5 threads (target='dev')
07:40:38
07:40:38  1 of 2 START sql view model dbt_jcohen.model_one ............................... [RUN]
07:40:38  1 of 2 OK created sql view model dbt_jcohen.model_one .......................... [CREATE VIEW in 0.13s]
07:40:38  2 of 2 START sql view model dbt_jcohen.model_two ............................... [RUN]
07:40:38  2 of 2 OK created sql view model dbt_jcohen.model_two .......................... [CREATE VIEW in 0.04s]
07:40:38
07:40:38  Finished running 2 view models in 0 hours 0 minutes and 0.32 seconds (0.32s).
07:40:38
07:40:38  Completed with 1 error and 0 warnings:
07:40:38
07:40:38    on-run-start failed, error:
 column "askdjf" does not exist
LINE 2: select askdjf
               ^
07:40:38
07:40:38  Done. PASS=2 WARN=0 ERROR=1 SKIP=0 TOTAL=3

This is important to support use cases where users want to define custom "project checks" that run before models are built — sort of like pre-commit hooks — and raise a compiler error if the check fails. For example, this discourse post which I linked in the comment above.

Hello! We have some code that runs on the "on-run-start" hook. If this code fails to run, we would like the entire process to stop at that point. We expect the pre and post-hooks to also cause the process to fail and stop if there are any SQL errors. It would be great if this could be included, but if not, could it be made configurable? This way, everyone will be satisfied. ;)

We expect the pre and post-hooks to also cause the process to fail and stop if there are any SQL errors.

I believe this is already the way pre and post-hooks work. This issue is to do the same for on-run-start and on-run-end.

Lightly editing questions from @katarinagacnik here:

since this behavior changed, we lost the ability to forcefully end the run.
Do you have any alternative solutions for this? How could we force exit() dbt run automatically when certain conditions are met?

@jtcohen6 what are the workarounds that you mentioned here?

In the meantime, there are workarounds to achieve this sort of behavior in a multi-step dbt deployment.

Hi, I'm wondering any updates around this issue? We also want to stop the subsequent process when an exception is raised in the on-run-start hooks.

I think I understood the behavior of this.

I have a similar context here where I want to block users from running a dbt command without a select flag. For that I have this macro:

{% macro check_select_arg() %}

    {% if
        not invocation_args_dict.select
        and target.name not in ['prod']
    %}

        {{ exceptions.raise_compiler_error("Error: You must provide at least one select argument") }}

    {% endif %}

{% endmacro %}

I added it to dbt_project.yml and It worked fine. It always raised a compilation error every run:

(venv) vitor_weiss@vitor-weiss ~/dbt $ dbt test
19:07:49  Running with dbt=1.7.10
19:07:50  Registered adapter: databricks=1.7.0
19:07:50  Unable to do partial parsing because saved manifest not found. Starting full parse.
19:07:53  Encountered an error:
Compilation Error in operation dbt-on-run-start-0 (./dbt_project.yml)
  Error: You must provide at least one select argument
  
  > in macro check_select_arg (macros/general_config/check_select_arg.sql)
  > called by operation dbt-on-run-start-0 (./dbt_project.yml)
(venv) vitor_weiss@vitor-weiss ~/dbt $ dbt test
19:08:06  Running with dbt=1.7.10
19:08:07  Registered adapter: databricks=1.7.0
19:08:07  Unable to do partial parsing because saved manifest not found. Starting full parse.
19:08:11  Encountered an error:
Compilation Error in operation dbt-on-run-start-0 (./dbt_project.yml)
  Error: You must provide at least one select argument
  
  > in macro check_select_arg (macros/general_config/check_select_arg.sql)
  > called by operation dbt-on-run-start-0 (./dbt_project.yml)
(venv) vitor_weiss@vitor-weiss ~/dbt $ dbt test

But later, I realized that I needed to add another condition to my macro that only blocks certain commands (build, test, ...) as below:

{% macro check_select_arg() %}

    {% if
        not invocation_args_dict.select
        and target.name not in ['prod']
        and invocation_args_dict.which in ['build', 'run', 'test', 'source', 'snapshot']
    %}

        {{ exceptions.raise_compiler_error("Error: You must provide at least one select argument") }}

    {% endif %}

{% endmacro %}

After that, my macro stopped blocking the execution of dbt, although it generated a database error as @jtcohen6 showed us.

If I remove my target folder and use the macro for the first time, without changing it, it works as expected. If I modify anything in the macro it changes the behavior, allowing it to run even when a compilation error occurs. Perhaps this could lead to a solution, knowing how to reproduce the error and the “normal” behavior.

I'm using dbt 1.7.10 by the way.

If I remove my target folder and use the macro for the first time, without changing it, it works as expected. If I modify anything in the macro it changes the behavior, allowing it to run even when a compilation error occurs.

@vitorweiss The actual vs. expected behavior you describe here sounds like it is working the way you want when dbt does not use partial parsing, but doesn't work they way you want otherwise.

Workaround

If so, then you can add the --no-partial-parse flag to get your desired behavior. In v1.8+, this can be set in your dbt_project.yml like this:

# dbt_project.yml
flags:
  # set default for running this project -- anywhere, anytime, by anyone
  partial_parse: false

Other feature request

Maybe #10323 could be expanded to also cover errors in addition to warnings 🤷

Namely, always raise warnings (and errors!) in every invocation, even when partial parsing is used.

Opened a new issue in dbt-labs/docs.getdbt.com: dbt-labs/docs.getdbt.com#6172