[
https://issues.apache.org/jira/browse/AIRFLOW-6535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17109153#comment-17109153
]
ASF subversion and git services commented on AIRFLOW-6535:
----------------------------------------------------------
Commit 707bb0c725fbc32929eea162993aa8fb9854fa9a in airflow's branch
refs/heads/master from Jonathan Stern
[ https://gitbox.apache.org/repos/asf?p=airflow.git;h=707bb0c ]
[AIRFLOW-6535] Add AirflowFailException to fail without any retry (#7133)
* use preferred boolean check idiom
Co-Authored-By: Jarek Potiuk <ja...@potiuk.com>
* add test coverage for AirflowFailException
* add docs for some exception usage patterns
* autoformatting
* remove extraneous newline, poke travis build
* clean up TaskInstance.handle_failure
Try to reduce nesting and repetition of logic for different conditions.
Also try to tighten up the scope of the exception handling ... it looks
like the large block that catches an Exception and logs it as a failure
to send an email may have been swallowing some TypeErrors coming out
of trying to compose a log info message and calling strftime on
start_date and end_date when they're set to None; this is why I've added
lines in the test to set those values on the TaskInstance objects.
* let sphinx generate docs for exceptions module
* keep session kwarg last in handle_failure
* explain allowed_top_level
* add black-box tests for retry/fail immediately cases
* don't lose safety measures in logging date attrs
* fix flake8 too few blank lines
* grammar nitpick
* add import to AirflowFailException example
Co-authored-by: Jarek Potiuk <ja...@potiuk.com>
> add exception subclass to fail immediately without retrying
> -----------------------------------------------------------
>
> Key: AIRFLOW-6535
> URL: https://issues.apache.org/jira/browse/AIRFLOW-6535
> Project: Apache Airflow
> Issue Type: New Feature
> Components: documentation, models
> Affects Versions: 1.10.10
> Reporter: Jon Stern
> Priority: Minor
>
> I would like to be able to configure certain tasks to retry, but to also have
> a way to bypass retry if I can detect a condition that is unlikely to be
> change for the better.
> For example, imagine I have a DAG with a large number of tasks that fetch
> data from an API ... sometimes the API returns a 200 and everything is fine,
> sometimes the API returns a 500 and I know this means that API is failing
> under load and I want to retry later, and sometimes the API returns a 400
> indicating that I've configured my requests in a way that will never succeed.
> If the API returns a 400 for some/all of my tasks, then I have to wait for
> all of them to get through all their retries before the run fails.
> My proposal is to add another subclass of AirflowException called
> AirflowFailException, and to update the exception handling in
> TaskInstance.run_raw_task such that when this exception is seen, the
> resulting behavior is that same as if we entered handle_failure and
> is_eligible_for_returned false (except with adjusted logging so it does not
> look like we simply hit our retry limit).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
