I m struggling to wrap my head around how state signals inte

Question

I m struggling to wrap my head around how state signals interact with the `retry delay` attribute of `Task` objects Based on the description of <https docs prefect io core concepts execution html state signals|state signals here> I d expect to be able to raise `signals RETRY ` and have the task wait `retry delay` before the task is run again However the retries appear to be being carried out immediately Can someone explain where I m going wrong in the `wait until success` task in the trailing code snippet

Andrew Lane · Answer

```from datetime import timedelta from time import perf counter from typing import Callable from prefect import task Flow from prefect engine import signals def get status func gt Callable str Returned function mocks an API call that returns Running for the first three calls and then returns Succeeded for every subsequent call n calls = 0 def get status gt str nonlocal n calls n calls += 1 if n calls lt 3 return Running else return Succeeded return get status get status = get status func task max retries=10 retry delay=timedelta seconds=5 def wait until success gt None status = get status if status == Succeeded return else raise signals RETRY with Flow test delay as flow wait until success if name == main start time = perf counter flow run end time = perf counter print f Run time s end time start time ```

Andrew Lane · Answer

I d expect minimum run time to be 15 seconds 3 retries with 5 second `retry delay` but the run is complete in under 1 second ```$ python delay py 2022 03 17 16 42 17+0000 INFO prefect FlowRunner | Beginning Flow run for test delay 2022 03 17 16 42 17+0000 INFO prefect TaskRunner | Task wait until success Starting task run 2022 03 17 16 42 17+0000 INFO prefect TaskRunner | RETRY signal raised RETRY None 2022 03 17 16 42 17+0000 INFO prefect TaskRunner | Task wait until success Finished task run for task with final state Retrying 2022 03 17 16 42 17+0000 INFO prefect FlowRunner | Flow run RUNNING terminal tasks are incomplete 2022 03 17 16 42 17+0000 INFO prefect FlowRunner | Beginning Flow run for test delay 2022 03 17 16 42 17+0000 INFO prefect TaskRunner | Task wait until success Starting task run 2022 03 17 16 42 17+0000 INFO prefect TaskRunner | RETRY signal raised RETRY None 2022 03 17 16 42 17+0000 INFO prefect TaskRunner | Task wait until success Finished task run for task with final state Retrying 2022 03 17 16 42 17+0000 INFO prefect FlowRunner | Flow run RUNNING terminal tasks are incomplete 2022 03 17 16 42 17+0000 INFO prefect FlowRunner | Beginning Flow run for test delay 2022 03 17 16 42 17+0000 INFO prefect TaskRunner | Task wait until success Starting task run 2022 03 17 16 42 17+0000 INFO prefect TaskRunner | Task wait until success Finished task run for task with final state Success 2022 03 17 16 42 17+0000 INFO prefect FlowRunner | Flow run SUCCESS all reference tasks succeeded Run time s 0 187956337002106```

Kevin Kho · Answer

If you `raise FAIL` it will respect the retry delay because that is a delay before getting queued in the retry state I think If you `raise RETRY` you bypass that

Andrew Lane · Answer

Right so we replace `signal RETRY ` with `signal FAIL ` in cases where something has gone wrong but we want to retry Is there a way to bypass the retry step and really fail if something that we know is irrecoverable has happened

Andrew Lane · Answer

A custom `state handler` perhaps

Kevin Kho · Answer

You can use the `ENDRUN` signal for that ENDRUN is on a task level not Flow level

Andrew Lane · Answer

Ah perfect Thank you