SQLite often errors out on this with only `interrupted (9)` as message.
This logging should at least tell us whether it's our own "background
context" timing out, or whether something else fishy is going on.
Fix workers timing out when they're `asleep`. When sleeping, the Worker
will call the `WorkerState` operation to see if they have to wake up, but
that didn't mark the workers as "seen". As a result, a sleeping worker
would always time out.
Change the `FlamencoVersion` schema definition so that it follows the style
of the other schema definitions:
- List properties before mentioning which are required.
- Put quotes around the property names, so that they stand out from the
other YAML keys.
Run some API operations in a background context. This should prevent some
of the SQLite "interrupted" errors, as those can occur when the context
closes while a query is running.
The API operations that Workers use are now mostly running in a separate
background context, at least from the moment onward when they can run
independently of the Worker connection.
Improve the "my own URLs" construction, such that:
- IPv6 link-local addresses are always skipped. They require a "zone index"
string, typically the interface name, so something like
`[fe80::cafe:f00d%eth0]`. This is not supported by web browsers, so the
URLs would be of limited use. Furthermore, they require the interface
name of the side initiating the connection, whereas this code is used to
answer the question "how can this machine be reached as a server?"
- IPv4 addresses are sorted before IPv6 addresses. Even though I like IPv6
a lot, IPv4 is still more familiar to people.
- Loopback addresses (::1, 127.0.0.1) are sorted last, so that the First-
Time Wizard is most likely to use the bigger-scoped address.
Every time the web interface starts, it queries the config to see whether
it should be in first-time-wizard mode or not. This caused unnecessary
info-level logging.
In the future it would be better to load the config file just once,
instead.
Use `backendURL()` function to construct API and Add-on URLs, so that they
work regardless of what is serving the webapp (Flamenco Manager or the
Vite development server).
For development of the web interface, to get a less predictable order of
asynchronous requests, the API responses were artificially delayed. This
was supposed to be optional, to be enabled via the `-delay` CLI argument,
but somehow the optionalness either never made it in or was mysteriously
removed.
The task log API endpoint was loading the entire log into RAM, then sending
it as response. This makes display in a browser also a bit harder.
The API endpoint now returns some JSON with info about the task log,
including its size and which URL can be used to download it.
Manifest task: T99730
The generators always produce UNIX line-ends. This creates false file
modifications with Git on Windows. Convert them to DOS line-ends to avoid
this.
This was already done for the Go code; this commit just copies the approach
to the Python and JavaScript generators.
My way to get things working (I wouldn't call this a "solution" as I don't
know the root cause) was to emit two consecutive "reshuffled" events when
changing tabs in the job details, and to recalculate the table height when
the job type (so not the job itself, but its type info) is loaded.
For some reason, on Windows, creating a directory with zero permissions
still allows creating a file in there. Just skip that part of the test.
The Explorer's properties panel of the directory also shows "Read Only
(only applies to files)", so at least that seems consistent.
Add a `-pprof` CLI option to enable the profiler. It will expose profiler
info on the web interface at `/debug/pprof/`.
To have a nice view of this, including flame graphs, run:
```
go tool pprof -http localhost:8082 http://localhost:8080/debug/pprof/profile
```
Be more selective in what's saved to the database to speed some things up.
Most importantly, this avoids saving the entire job when a task status is
updated or a task is assigned.
Add a SHA256 password hasher for worker authentication. It's not used at
the moment, but can be switched to for faster API queries. Note that
switching will cause authentication errors on already-existing workers,
which means they'll automatically re-register.
This is mostly useful for debugging & profiling purposes.
Move the Worker password hashing/comparison functions into a struct, and
use it via an interface. This will make it easier to switch to different
hashing algorithms.
Even with a low number of iterations, BCrypt is quite slow. That's good for
security, but not for Flamenco Worker authentication -- the password is
more as "nice check to avoid accidentally reusing the same ID" than
something for security.
Build with `make stresser`. Run with:
./stresser -worker UUID -secret ABCXYZ
The worker ID and secret can be obtained from
`flamenco-worker-credentials.yaml`. If left empty, the stresser will
register as a new worker, and log the credentials to be used on the next
invocation.
In the first-time wizard, if Blender cannot be found on $PATH but it can
be found via .blend file association, that should just be reported as a
normal sitation, and not as a `500 Internal Server Error`.
