basaltd 0.8.5

Upgrade if you are running 0.8.4. This fixes a bug that can stop a vault
syncing entirely.

A batch that cannot commit still commits

0.8.4 started committing a device's batch as one transaction: one fsync for a
hundred notes instead of a hundred. That is a real speedup and it is the right
default. What it did not have was anything to fall back on.

On my own server, a day after upgrading, every batch a device sent was being
refused with disk I/O error (6410). The device connected, offered its work,
was refused, the session ended, and it tried again three seconds later, twenty
two thousand times in a day. Nothing was lost, because nothing was
acknowledged. Nothing synced either.

0.8.5 falls back to committing one entry at a time whenever the batch cannot
commit. That is what every release before 0.8.4 did: it costs an fsync per
entry and it works. A speedup that can stop a vault syncing is worse than the
fsyncs it saves.

And a likely cause of that error

6410 is SQLite asking where it may put a temporary file. The published image
is built FROM scratch and has no /tmp in it, and a SAVEPOINT, which the
batched commit uses, is what makes SQLite want a statement journal in one. So
0.8.5 also sets temp_store = MEMORY, which keeps that scratch space in the
process.

When I wrote this I could not reproduce the failure, and said the pragma went
in as the correct setting rather than as a diagnosis. Deploying it changed
that. The server that had refused 461 batches in its last half hour on 0.8.4
committed the device's waiting work within seconds of starting on 0.8.5, and
in the five minutes after: zero errors, one stable session instead of a
reconnect every four seconds, and the fallback never fired. The batch
committed as a batch, on the one code path the pragma touches.

That is strong evidence and still short of proof, because the container was
also recreated and I never reproduced the failure in a controlled setting.
What would settle it is a 0.8.4 image with only the pragma added, on that
host. The fallback stays in regardless: it is what makes the next unreproducible
store failure a slow vault instead of a stopped one.

Upgrading

The protocol is unchanged, so clients on 0.8.4 and 0.8.5 both work against
this. Pull the new image and restart; nothing in your data directory changes.