When the job status changes, it impacts the task statuses as well. These
status changes are now no longer done with a single database query, but
instead each affected task is fetched, changed, and saved. This unifies
the regular & mass updates to the tasks, and causes the resulting task
changes to be broadcast to SocketIO clients.
Manager now sends out task updates via SocketIO, and the web interface
handles those.
Note that there is a `BroadcastTaskUpdate()` function, but not a
`BroadcastNewTask`. The 'new job' broadcast is sent after the job's
tasks have been created, and thus there is no need for a separate
broadcast per task.
The version number used in the OpenAPI-generated code shouldn't contain
the `-dirty` suffix. In the common development workflow, those files
will always be dirty; because they're only committed after things are
locally working, the implementation has already been written.
SocketIO clients can now send a message with `/subscription` event type
in order to subscribe to or unsubscribe from job-related updates.
These job-related updates themselves aren't sent yet, so this is a change
that's impossible to really test. The socketIO code for joining/leaving
rooms is called, though.
A client can send a `SocketIOSubscription` object with the
`/subscription` event type, in order to manage the subscriptions to
job-related updates.
Subscribing to a job means receiving updates to its tasks. General job
updates are sent to all clients anyway.
This commit only contains the OpenAPI YAML change, to see if it works
well to separate such commits into three parts:
- OpenAPI definition change.
- Regenerated code changes.
- Hand-written code changes.
The project was created with things (components, router, views) we don't
use at the moment. To keep a clearer separation between "our code" and
"example code", I just removed the latter.
Add `fetchJobTasks` operation to the Jobs API. This returns a summary of
each of the job's tasks, suitable for display in a task list view.
The actually used fields may need tweaking once we actually have a task
list view, but at least the functionality is there.
This commit includes settings for Visual Studio Code, so that at least
different people with the same editor (or me on multiple machines) get the
same formatting.
No functional changes.
A wrapper for the generated `ApiClient` class tracks the number of running
queries. This makes it much simpler to show the "API calls pending" UI
element, regardless of which part of the webapp performs the queries.
Completely flush the upstream buffer at startup, before attempting to
fetch a new task. These updates could impact any task on the Manager side,
and first flushing the buffer before appending new updates also seems
like a good idea.
The password check of worker API calls was 2 orders of magnitude slower
than actually handling the API call itself. Since the Worker authentication
is not that important (it's all on the same network anyway, and Worker
account registration is automatic too), lowering the BCrypt cost to the
minimum helps.
On my machine, this reduces the time for password checks from 50 to 2 ms.
