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.
The synchronous executor was missing a call to ResultIterator.Release.
The asynchronous executor wasn't even calling Query.Statistics.
Also add a test that the scheduler records the statistics to the run
log, and that the statistics are visible from the launcher test. The
launcher test is the most likely place to catch if something goes wrong
in the full stack.
The late measurement filter, after a pivot, had the potential to result
in empty groups without a runID, which would cause a runtime error,
which would cause the whole query to fail.
Experimentation has shown that those empty tables will no longer arrive
by filtering early on measurement.
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.
Task ID is now a required value on run and log filters. It was
effectively required by all implementations before anyway, so now those
types reflect that requirement.
Organization ID was removed from those same fields. The TaskService
looks up the organization ID via the task in cases where we need it at a
lower layer.
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.
In TestScheduler_RunLog, the run log gets updated asynchronously so we
need to poll to ensure we don't read a stale value.
In TestScheduler_CreateNextRunOnTick, we were previously reading the
one entry out of two from a map, so it was often the entry we weren't
interested in.
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.
Lyon Hill
Delmer
Mark Rushakoff
Mark Rushakoff
docmerlin (j. Emrys Landivar)
Leonardo Di Donato
Michael Desa