I wanted to know what would be the best practice (or any gotcha's) when trying to have the autotask rerun its code.
For example, if an autotask is looking for a particular result from an api call (ie. bid/ask price data), I would like for it to retry the call (ie. after x seconds) if the bid/ask spread is too wide. This is not an api call failure, but just an undesirable result in which we want to try again in hopes of a more accurate value.
I know there is a 5 second timeout, which may prevent us from doing this looping pattern.
**Using Sentinel Events **
My work around idea would be to have the autotask trigger an event on the smart contract (ie. AutotaskRetryEvent) that the sentinel will pick up and run the autotask again. I believe this would create the loop I am looking for, but since each autotask run is in isolation, I am not sure there is a way to break this loop after "X" attempts.
Is there any elegant solution for dealing with undesirable results from an autotask that would require you to possibly run it a couple more times in an attempt to have a successful/usable output?
Hey @Guceri, that's a very good question! Can you give a bit more details on the expected time between retries? Would it be in the order of a few seconds, or could be a few minutes? If 5 mins is acceptable, my suggestion would be to run the autotask every 5 minutes, and check if you need to run again or not. You can use the key-value store to keep track of the successful/failed runs, or pass messages between different autotasks.
The key:value store ability is a great autotask functionality! Is this new? Not sure how I missed this.
On a high level, our autotask will be targeted once a week to run logic and send data to our smart contract. That would mean +90% of the time, the code will not trigger any transactions if ran every 5 mins.
If this does not hit OZ Defender account limits or restraints, then this could be a good solution to work with. I was originally going to wait for the cron job expressions that you plan to roll out, but given the need to retry on bad data, it might make sense to take the scheduled approach instead.
The process for what we are using autotask will follow this general pattern:
Nothing downstream works without the valid external price data from step 1.
We give ourselves a 1 hr buffer between step 1 & 2 to resolve any issues before we move on to the next process(ie. no data, bad data, api failure, autotask failure, etc.) .
The 6 hr gap between step 2 & 3 is an Auction that we will be running. At the completion of the auction, we will invoke that contract to settle the auction.
My initial thought here is to then just use the 5 min scheduling, with a Time & Key:Value conditional for each of the 3 steps above. Let me know if that is how you see it as well. The autotask Key:Value store seems to be the critical piece I was looking for.
@Guceri the approach looks good! And cron expressions are finally coming first week of November, so you should be able to restrict the first autotask to run every 5 minutes but only from 8AM to 9AM on Fridays.
Regarding this, the current limit for the Team plan is 120 autotask executions per hour. If you run this every 5 minutes you should be good, but let us know if other autotask runs could put you over this limit and we can temporarily increase your quota until we roll out cron expressions.
Is there a getter/setter in the UI? I can think of a few edge cases where it might require resetting storage values to re instate a process if we run into issues.
For example, if we use booleans to determine when a autotask function runs, we might need to reset the boolean in order to invoke the function again for whatever reason.
I noticed there is significant room to add new key:values if needed which could be a work around.
Not at the moment, the only way to interact with the store is from an Autotask. A workaround could be to set up a one-time autotask that you run manually and updates the entries you need.