A worker state change request can now be cancelled by requesting the worker
to go to its current state. In other words, a previously requested change
`A → B` can be cancelled by requesting the worker goes to state `A`.
Previously this would simply overwrite the last request, resulting in a
requested state change `A → A`. Having this non-lazy would even interrupt
the currently running task.
Instead of always passing `status_requested` and `lazy_status_request`
in tandem, and requiring one when the other is present, they are now
always passed as a struct `WorkerStatusChangeRequest`. This struct has
both fields required.
`WorkerStatusChangeRequest` already existed, and is now altered by changing
its field `status_requested` to simply `status` -- the fact that it's
requested is already clear from the context.
rFcfb17b178da2055ef12b2aa2ad8f7f778a952bc3 changed the semantics of
`SocketIOWorkerUpdate`, in the sense that any update that doesn't change
the worker status can omit `previous_status`. This commit adjusts the
unit test for this.
This also introduces the 'lazy' status change boolean, which indicates
whether the status change should interrupt the worker's current task
(lazy=false), or only take effect after the task is finished (lazy=true).
SocketIO clients no longer automatically subscribe to the jobs updates.
This is now done explicitly via the `allJobs` subscription type, and
unsubscribing is also possible.
When the web interface is showing the Workers list, it should no longer
get updates about jobs. A new subscription type `allJobs` is added, and
the `uuid` field of the subscription is no longer mandatory.
The tasks table resize function is called via `this.$nextTick()`, which
means that the component can actually already be unmounted by the time
the actual function call is performed. This is now detected & handled.
Ignore those files regardless of the path. Previously they were only
ignored in the project root, but I want to create several worker
configurations in a subdirectory for testing.
A task's "activity" field is a string that describes the last-performed
operation on the task. In Flamenco 2, a Worker's "last activity" is the
timestamp at which it was last seen. Using the same term for different
things is confusing, and thus gets removed until the Worker's "last seen"
functionality is reimplemented.
A task can exist in the database but not have any log stored on disk yet.
This is now returned as `204 No Content` instead of an internal server
error.
The web interface is also adjusted to cope with this.
