Open filex opened 1 month ago
For jobs with longer intervals it doesn't really matter if the first job is issued 1s or 1m after startup. So we could even decide to define the startup_delay
with a non-zero default value such as 1m
.
I would consider jobs with very short intervals (like 10s or even less) the exception. In that case the user could explicitly disable the startup_delay
if that really is an issue.
There are a couple of alternative solutions that are all more complex:
schedule
attribute that accepts cron syntax. This would make the invocations independent from the startup
The
jobs
configure theinterval
. That is the duration between two invocations of thejob
. The first is "on startup" of Couper.I had a situation, where I have a kube pod with two containers: Couper and a node-based API server. When the pod is rolled out, both containers start in parallel. Usually, Couper is faster and executes the jobs while the pod-local backend is not available yet. (This results in errors like
cannot connect to http://localhost:3000
).The purpose of the execution on startup was, that the interval is not aligned (e.g. with 00:00 midnight). So instead of waiting for one interval before the first execution, we do it immediately. If the first execution is doomed to fail, we risk to maximize the time to the first job execution.
An easy solution could be to mitigate the problem is introduce a startup delay for the job:
In this example, Couper would issue the first job 1 minute after startup. And thereafter, every hour.