Task updates now attempt to keep the existing runners working.
This causes the system to be slightly slower after a task update and caused a flakey test.
This should considerably simplify debugging when things go wrong with
the tasks, as this error can be displayed from the UI or CLI. Prior to
this change, you would have to view the console output from influxd.
Fixes#12548.
This was a missed case from #11817.
This case currently occurs when creating a task through the UI, using a
session rather than a full-fledged authorization. It doesn't fix that
case yet, but at least it will log an informative message.
I did this with a dumb editor macro, so some comments changed too.
Also rename root package from platform to influxdb.
In interest of minimizing risk, anyone importing the root package has
now aliased it to "platform" so that no changes beyond imports were
necessary in those files.
Lastly, replace the old platform module to local path /dev/null so that
nobody can accidentally reintroduce a platform dependency while
migrating platform code to influxdb.
Previously, the WithTicker option would call TickScheduler.Tick every
time the underlying time.Ticker sent a time on its channel. This meant
we used a 1s period, which meant that in the worst case, we would see a
tick at about 999ms after the second rollover.
This change increases the underlying time.Ticker frequency, but only
calls TickScheduler.Tick after a second rolls over. Since we now use a
tick frequency of 100ms, during normal operation, TickScheduler.Tick
will be called within 0.1s after the second rolls over.
This is to ensure that Scheduler.Stop blocks until outstanding task runs
finish. There were enterprise tests failing because outstanding runs of
a task were calling (*testing.T).Log after the test finished.
This also changes the backend.Store API to remove the EnableTask and
DisableTask methods, merging their functionality into ModifyTask, which
has been named to UpdateTask to keep closer to the CRUD acronym.
Introduce a RunLogBase type that encapsulates the base information
shared across multiple logs for the same run. This has the information
previously part of the API (Task and RunID), and includes the addition
of a RunScheduledFor timestamp.
Also remove the RunScheduled value for RunStatus, as it was never used
in the scheduler.
A mistake in the WithTicker method caused it to block.
This was not evident because until recently we used a cron styler timer.
Removing the block should allow the task deamon to start up properly.
The logic used to be only in the scheduler, but now Options exposes it.
This is another step towards making StoreTaskMeta schedule-aware to
enable creating manually requested runs.
More specifically, introduce a `scheduleAfter` argument to
Store.CreateTask. The previous behavior was leaving a new task's meta
LatestComplete value set to zero, which meant that the first run of a
schedule would start from 1970. Now, it's set to time.Now unless
otherwise specified.
Updates #595.
We were previously doing `r.logger = r.logger.With(...)`, which ended up
duplicating the provided field in the log output. Now ensure that we
only set the run_id once in a logger.
Lyon Hill
Jacob Marble
Mark Rushakoff
Jacob Marble
Jonathan A. Sternberg
Mark Rushakoff
docmerlin (j. Emrys Landivar)
Leonardo Di Donato
Jade McGough