using Task `timeout`: I have a task where I’ve set the

timeout

argument. This causes all tasks of this type to not report their completion! I see on the agent itself that their execution is done, but there’s no call to the state handler to change state to complete, or to write the task result, as is normally the case with the tasks. Here’s the gist of my task definition; when I remove the line setting

kwargs['timeout']

everything works.

TIMEOUT = 10. # minutes
class MyTask(Task):
    def __init__(
            self,
            param1 = None,
            param2 = None,
            cache: bool = False,
            **kwargs
    ):
        self.cache = cache
        if 'max_retries' not in kwargs and 'retry_delay' not in kwargs:
            kwargs['max_retries'] = DEFAULT_MAX_RETRIES
            kwargs['retry_delay'] = timedelta(minutes=DEFAULT_RETRY_DELAY)
        kwargs['timeout'] = TIMEOUT * 60  # If I remove this line, everything works great
        super().__init__(**kwargs)
    def run(self, param1=None, param2=None):
        # Code!

I fear it’s a bug in prefect but not sure. Would love to get some input before I open an issue

Hi @Avi A, I’m taking a look at your specific situation here but you may be interested in https://github.com/PrefectHQ/prefect/issues/1808

Thanks @Laura Lorenz (she/her), Chris raises good points there. Why did you decide to not deprecate it in the end?

Ah ok yeah I was about to link to Alex’s comment — I wasn’t at the offline discussion but I think that’s more or less the state of it now, we have briefly talked internally about trying to expand the coverage of timeout support in different executors but it hasn’t been high priority yet (and wouldn’t necessarily solve your problem since we know there is a limit to what timeouts will support). I will add this convo and anything I observe while reproducing your situation to that ticket in any case to bump it! What executor/environment and/or agent are you using?

agent: local env:

RemoteEnvironment(executor="prefect.engine.executors.LocalDaskExecutor")

Awesome, thanks! One other thing I can say from a feature perspective is that we are in the beginning times of working on “cancellation” — to try and support (at least in some environments) the concepts of ad hoc cancelling tasks/flows that have already started, which I think can (/will) bleed into better support for the

timeout

kwarg. I’ll make sure to follow up on that side of things too as that project is going on 🙂

yeah if you could implement cancellation,

timeout

might come at almost zero cost. But I want to stress that this feature is not that crucial for me, I used it b/c I thought it was there, and didn’t realize it would cause problems with log reporting. I think that documenting the caveats is a good solution for the time being.

Ok gotcha! 👍