Is it possible to modify the default timeout time? What is it by default?
Environment
Any
Details
Running several .call() functions make the autotask to fail because it runs out of time.
Code to reproduce
Hi @Fede
I assume we are talking about Autotask timeouts.
Autotasks are executed in a node 12 runtime with 256mb RAM and a 5-minute timeout.
https://docs.openzeppelin.com/defender/autotasks#environment
In case additional info is needed please share your autotask id (visible in the url when specific autotask page is opened).
Best regards,
Zeljko
Thanks for the answer! Is it possible to change this param? To have a larger time out?
Currently this is hard limit and it is not possible to change it per account.
We are interested to hear about your use case and what are main reasons for this increase.
We are constantly improving Defender and requests like this one could get into our development backlog.
1 Like
Is there any way to be able to re-start a failed autotask? E.g, my autotask failed because of a task time out, can I detect that some how and automatically restart it?
HI @Fede,
You can use our Defender API. Specifically Autotask Runs Endpoints or defender-autotask-client NPM package.
You can list your latest Autotask runs and check the status. Then trigger manual run endpoint to try rerunning it.
I hope this helps!
1 Like
So, I'd create a "Retrier" autotask which runs, for example, every 5 minutes that:
- Gets all autotasks
- For each autotask:
const runs = await client.listAutotaskRuns(AUTOTASK_ID);- Get the latest one from the array
const latestRun = runs[runs.length - 1] - If latest run status is FAILED, call
await client.runAutotask("AUTOTASK_ID");
Right?
And, in the case a task has successfully completed but it has created a TX which is still pending and then fails (either because Defender has tried several times and validUntil has been hit or because the transaction actually failed), how can I retry?
Hey @Fede,
I've looked into this and I can confirm that you can't import defender-autotask-client inside the autotask itself. So your approach won't work.
Instead you can have your own server using defender-autotask-client and doing the retry business logic based on the latest runs statuses.
I hope this helps 
P.S I will create a user request internally for Autotask retry feature and will let you know if/when we implement it.
Hi guys.
Loving Defender but the 5 minute timeout is a real bummer. We have some long running work to do: checking the state of hundreds, maybe thousands, of positions in our defi app, and taking appropriate action on chain. But this can take more than 5 minutes, and we end up having to jump through hoops just because of the 5 minute limit (e.g. breaking work into smaller chunks, and saving state so that we can recover from timeouts).
Obviously we could totally redesign the thing we are writing to do most of the work outside an autotask context on some other server, and then call into autotask just for the on-chain transactions, but this is more work and involves writing a bunch of valueless boilerplate code, and our hope was/is that using defender can save us that sort of work.
I assume there's a good reason why the timeout can't easily be made configurable given you've not done it already, so perhaps you can fill us in on the rationale? If nothing else it might make the seemingly-arbitrary timeout less frustrating!
My first thought was that it is there so that we don't abuse CPU, but we can schedule a 5 minute autotask to run every hour (or more frequently) via chron, which seems to cost more CPU time than (say) a half hour task run once a week or even once a day.
Thanks.
CR
Hi @CyclopsRex
Thanks for your feedback.
In general there are some hard limits when workings with Autotasks that would be hard to change with current approach.
We are using AWS Lambdas to execute Autotask logic and it is well known that maximum execution time for AWS Lambda is 15min.
In general Autotasks are intended for simple actions. For complex computations best to use other systems.
I will create internal ticket to track this request.
Best,
Zeljko