Is there currently a way to only run a schedule if it has actually completed executing and processing.
I have a schedule that runs every 5 minutes, however sometimes the script could take 6 minutes to complete its last action, so I do not want to run it again if its still running from previous.
At the moment I write a field to a database table when the schedule starts, and update the value when it completes, and have a condition saying do not run the actions in the schedule if the database is still value of running.
I am just wondering if there is a simpler way.
Maybe this could be solved with queues using Redis but I don’t know how to do that in the current Wappler structure. I’m also developing an application that has a minute-by-minute schedule, hadn’t thought of this problem until now.
I’m creating scheduled tasks as a regular server actions and tuning/debugging then as usual server actions and when they are ready - converting them to scheduled task.
A couple thoughts on how queues might help here. Requires node.
First, a queue can be setup to only run one job at a time, but also you can schedule the next job when the current one is finished. Basically you would not use the scheduler, you use the queues alone. Tobias has posted some code that can kick off the process on server start. You can also use this to control the delay before next job run. For example if the job does nothing, maybe you delay longer until it finds something to do.
But also, I have found that breaking long running jobs into smaller jobs ( often using a different queue) helps keep things manageable and efficient.
Sorry if stating the obvious here, but if you use a Library action for the logic, you can use that in the scheduled action AND have an api for testing.
Yeah sorry, I think I misunderstood. So what I do is I start off by creating the library action, as well as a normal action that executes or includes the library action, I do all my debugging, until I am happy with the results, and then create a schedule action that is almost identical to the normal test action, which generally has a single step, either execute or include.
Yes it’s one extra action for testing, but it’s only a single step, so very quick and easy to create and use.
Ken, with using queues as a possible option, how do you handle error reporting out of interest, so if the script from the second action in the queue has some error while running can it still be caught like a single action, hope that makes sense.