The current behavior is that the update is pushed into the scheduler,
and the scheduler cherry pick's what it needs. This leaves the task itself out
meaning any logging the scheduler did was not going to have the new task information in it.
Now that the run status updates are transactional actions
We no longer have to add a timer to keep things on track.
This is causing a problem where some runs are showing up without a start or stop time if the system is busy.
I would rather have the scheduler hang on the update then leave a run action without required fields.
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.
Alirie Gray
Lyon Hill
docmerlin (j. Emrys Landivar)
Sebastian Borza
Jacob Marble
Mark Rushakoff
Jacob Marble
Jonathan A. Sternberg
Mark Rushakoff
Leonardo Di Donato