Requeueing the tasks of a specific worker is now done in the
`TaskStateMachine`, such that it can be called from other services as
well in future commits.
This also makes the `LogStorage` service a dependency of the
`TaskStateMachine`, as it needs to write "this task was requeued" kind
of messages to the task logs.
SQLite doesn't handle timezones by default, when you just use something
like `date1 < date2`, for example. This makes GORM explicitly use UTC
timestamps for the `CreatedAt`, `UpdatedAt`, and `DeletedAt` fields.
Our own code should also use UTC when saving timestamps. That way all
datetimes in the database are in the same timezone, and can be compared
naievely.
The `TestTaskTimeout()` unit test assumes specific durations for initial &
subsequent sleeps of the timeout checker. The test will fail quite
cryptically when that assumption doesn't hold, so just test for it at
the start of the unit test.
Tasks that are in state `active` but haven't been 'touched' by a Worker
for 10 minutes or longer will transition to state `failed`.
In the future, it might be better to move the decision about which state
is suitable to the Task State Machine service, so that it can be smarter
and take the history of the task into account. Going to `soft-failed`
first might be a nice touch.
In the future different services will write to the task log, and thus
it makes sense to move the responsibility of prepending the timestamps
to the log storage service.
The requeue-task-on-worker-signoff operation also needs to log a timestamp.
The code for this, and the recently added code for timestamping the
"task assigned to worker" message, are now unified.
Having only the status dot was hard to read. It requires you to learn &
remember the different colours, or to mouse-over and wait to see the
tooltip. For accessibility, we shouldn't be using just the colour to
convey information in the interface.
The 720px was almost filling up the entire height, making it hard to add
anything new at the top. Soon it should be auto-resizing anyway, making
this less relevant.
UI/UX needs improvements, but there now are some buttons to manage Workers.
They request forced status changes, so nothing lazy yet. Still have to
consider how to include that in the UI. Could probably follow the
Flamenco 2 Manager design.
Making the UUID optional (rF221ed17fa27193086ec5c9201d48f7cd826e75a4) made
the generated JavaScript code ignore the 3rd parameter. Apparently the
constructor parameters are only for the mandatory properties, and the
rest has to be set on a per-property basis.
Remove the `shutdown` worker state. It was only used in Flamenco 2 to
signal to the worker that it should go offline. In other words, it didn't
use the target state in the request.
As of this change, just send `offline` as the requested state for the
worker if you want it to go offline.
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.
