What happened here is kind of a long story.
The TaskService tests exercise different parts of the TaskService
concurrently, in hopes of exercising code that may be racy. This worked
fine so long as we were able to use arbitrary user and organization IDs
picked during test.
Then we added tests for the http-client-backed TaskService. The instance
of http.TaskService takes a single token, so the TaskService tests were
updated to use an optional override to get the user and org ID from the
TaskService implementation.
That meant our parallel tests were using one user and org ID in some
cases. One particular test to exercise concurrency would create tasks
and then retrieve them and delete one. Because this test was filtering
by user and org, sometimes it would delete a task created in a different
test.
The fix was to maintain a whitelist of tasks created in that particular
test, so that it wouldn't delete tasks created in a different test.
This also adjusts the TaskService interface's RetryRun method to accept
a task ID rather than an org ID. Internally, we still look up runs by
organization, and maybe that will change later, but this is a more
natural way for clients to look it up.
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.
We changed the semantics of finding a task that doesn't exist, from
returning `nil, nil`, to `nil, ErrTaskNotFound`; this test didn't
reflect that change until this commit.
This renames TaskEnabled and TaskDisabled to TaskActive and
TaskInactive, to keep in line with the swagger and other parts of the
system. But I left the EnableTask and DisableTask methods on the Store
interface for now. I could see eliminating those methods if we adjust
the signature of the UpdateTask method.
The generate commands have been modified to take advantage of the new
functionality in Go 1.11 that allows `go run` to execute a package
instead of individual files.
This functionality combined with Go modules allows us to execute a
package directly out of our pinned dependencies rather than accidentally
picking up another binary outside of the build environment.
This also simplifies the Makefile because they no longer have to be
responsible for installing the correct tooling since the Go command
takes care of that logic. It also makes it so that the Makefiles with
file generation can now be invoked from their appropriate subdirectories
so they are contained within the directory itself rather than relying on
values in the top level Makefile.
It is now possible to generate all files within this project by using:
go generate ./...
Or the Makefile can continue to be used.
This commit also copies over the special copy of `tmpl` that the storage
engine uses within the influxdb repository. It was never copied over so
using `go generate` on these packages did not work.
We are moving the necessary code for 2.0 from the influxdb 1.X
repository to the platform 2.0 repository. The logger is an unnecessary
dependency on the old influxdb that is making life more complicated.
This iterface is supposed to be something that both sessions and
authorizations can share so that other components can authorize requests
as they see fit.
Mark Rushakoff
Nathaniel Cook
docmerlin (j. Emrys Landivar)
Lyon Hill
Adam
Jonathan A. Sternberg
Chris Goller
Leonardo Di Donato
Brandon Farmer
Michael Desa