Thank you for opening your first issue here! 🛠

Hello 👋, This issue has been inactive for over 9 months. To help maintain a clean and focused backlog, we'll be marking this issue as stale and will close the issue if we detect no activity in the next 7 days. Thank you for your contribution and understanding! 🙏

Commenting to keep open.

i really like this idea.
I think from a flytekit pov, it should be implemented like so

# retries is simply implemented using a retry class, similar to container_image=ImageSpec or str
@task(retries=BackoffRetry(interval=timedelta(minutes=2), count=3))
def foo():
   ...

In flyteidl, we can add it to RetryStrategy which is already a class.

In Flytepropeller we can add it to
Propeller's struct

and then to the computation logic here

We can use the last_updated_at from the node_status to wait for the retry.

This should not be too hard to do.
We can also implement exponential backoff

@kumare3 will it be possible to add a feature where a user can provide the delay for retry?

It is useful in case upstream system provides the delay mechanism

Yup absolutely- this is indeed the idea with retry strategy and implementation should be easy. But someone has to be contribute

@kdhingra307 join slack.flyte.org and we can collaborate

@kumare3 sure let's connect on slack once

As discussed if you just want the workflow to sleep / wait before task B, you can use Flytekit.sleep

Also nodes will be queued in case no resources are available