Implement no_retries_on_test_failure on DbtTestLocalOperator

[okayhooni]

Description

Added no_retries_on_test_failure parameter to DbtTestLocalOperator with a default value of True.
This parameter raises AirflowFailException, ensuring that failed DBT tests are not retried unnecessarily, even if a common retries value of 1 or more is set in DbtDag/DbtTaskGroup.

Unlike the on_warning_callback parameter, it does not seem necessary to propagate no_retries_on_test_failure through the converter and airflow/graph modules. Instead, similar to the callback parameter in AbstractDbtLocalBase, it can be passed via operator_args when needed.

Related Issue(s)

closes #1537

Breaking Change?

Nope.

Checklist

• [] I have made corresponding changes to the documentation (if required) -> Not needed in this case.
• I have added tests that prove my fix is effective or that my feature works

[netlify]

✅ Deploy Preview for sunny-pastelito-5ecb04 ready!

Name	Link
🔨 Latest commit	47ed26c
🔍 Latest deploy log	https://app.netlify.com/sites/sunny-pastelito-5ecb04/deploys/67c89cd2eca63800083915ce
😎 Deploy Preview	https://deploy-preview-1563--sunny-pastelito-5ecb04.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[pankajastro]

LGTM

[pankajkoti]

Hi @okayhooni, thanks a lot for the report and your contribution!

Apologies for the delayed review—I was out last week and have been catching up this week.

After discussing this internally with @tatiana, we feel it would be better to unify this configuration with our existing interface for similar scenarios. For reference, in PR #1492, we added support for overriding the profile per dbt node. Similarly, we think it would be more consistent to allow this configuration to be overridden at the test level for specific nodes and at the dbt_project.yml level for global application.

For example, similar to this configuration, we could support something like:

tests:
  jaffle_shop:
      +meta:
        cosmos:
          retries: 0

Another point to consider is that test failures may also occur due to connectivity issues, such as being unable to connect to the datasource. In such cases, it might make sense to retry the task. If we can determine the actual reason for the failure—whether it was due to a failed dbt check or a connectivity issue—then we could apply this configuration accordingly (perhaps by analyzing the logs).

Additionally, we might not want to disable retries by default, as it maybe considered breaking change for existing versions. Right now, tasks may retry for various reasons beyond dbt test failures, such as network interruptions.

Looking forward to your thoughts on this!

[okayhooni]

@pankajkoti I see your point, and it makes sense.

In our pipeline's use case, data testing is just an additional safeguard, and the test results should not impact the main batch flow. Because of this, retries for test tasks should generally be avoided, regardless of the reason for failure.

However, as you mentioned, a more precise approach would be to parse the error message from the dbt test command output to determine whether the failure was truly due to a data-related test issue. I'll work on improving the code to incorporate this logic when I have time..!

[pankajkoti]

hi @okayhooni we're planning to release Cosmos 1.10.0 sometime next week and wished to check if you'd have a chance to iterate on this PR ?