bvandeusenandClaude Opus 5.5
29042e4eb2
release / govulncheck (push) Successful in 29s
release / web (push) Failing after 1m21s
release / go (push) Successful in 1m39s
release / integration (push) Successful in 5m26s
release / android (push) Successful in 5m27s
release / Build signed APK (push) Successful in 5m44s
release / Attach APK to the Release (tag releases only) (push) Skipped
release / Build + push container image (push) Skipped
release / Verify release artifacts (tag releases only) (push) Skipped
A new server (no accounts, no library) offers "Restore a backup" beside "Create account". The file goes up as the request body to POST /api/auth/restore with the setup token from the log in X-Setup-Token, since the backup's admins become this server's. It loads in one transaction, then a library scan starts and finds each file at its path. The same load runs offline as `minstrel restore FILE`, which migrates the schema first. That path alone gets a 1 GiB, 15-minute body allowance instead of 4 MiB and 30s, and skips the JSON-only check for cookie writes: a stale cookie from the old server would otherwise refuse the upload, and the custom header already rules out a cross-site form. The library sync answers 410 cursor_ahead to a cursor past the last one the server has handed out, read from the change sequence, so an app synced with the old server after the backup was made starts over instead of skipping the ids the restored server reuses. Restore now leaves each sequence as having issued the restored maximum, so that reading holds; a compacted log still counts its handed-out cursors. backup.Read keeps the underlying error in its chain, so an oversized upload answers 413 rather than "not a backup". The hosting docs say how to put the music back first and what is entered again afterwards. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
39 lines
1.5 KiB
SQL
39 lines
1.5 KiB
SQL
-- name: InsertLibraryChange :exec
|
|
INSERT INTO library_changes (entity_type, entity_id, op)
|
|
VALUES ($1, $2, $3);
|
|
|
|
-- name: InsertLibraryChanges :exec
|
|
-- Batch form, for a mutation that touches many rows at once (the scan's
|
|
-- reconcile pass can mark up to a quarter of a library missing in one go). A
|
|
-- loop of single inserts would be thousands of round-trips inside a scan that
|
|
-- is already the slow path.
|
|
INSERT INTO library_changes (entity_type, entity_id, op)
|
|
SELECT sqlc.arg(entity_type)::text,
|
|
unnest(sqlc.arg(entity_ids)::text[]),
|
|
sqlc.arg(op)::text;
|
|
|
|
-- name: GetLibraryChangesSince :many
|
|
SELECT id, entity_type, entity_id, op, changed_at
|
|
FROM library_changes
|
|
WHERE id > $1
|
|
ORDER BY id ASC
|
|
LIMIT $2;
|
|
|
|
-- name: GetMaxLibraryChangeCursor :one
|
|
SELECT COALESCE(MAX(id), 0)::BIGINT FROM library_changes;
|
|
|
|
-- name: GetLastIssuedLibraryChangeCursor :one
|
|
-- The highest cursor this server has handed out, even once the compactor has
|
|
-- trimmed the rows: the id sequence's last value. A restored server's
|
|
-- sequence stands at the backup's last change.
|
|
SELECT COALESCE(pg_sequence_last_value(pg_get_serial_sequence('library_changes', 'id')::regclass), 0)::BIGINT;
|
|
|
|
-- name: GetMinLibraryChangeCursor :one
|
|
SELECT COALESCE(MIN(id), 0)::BIGINT FROM library_changes;
|
|
|
|
-- name: DeleteOldLibraryChanges :execrows
|
|
-- Removes library_changes rows older than the given cutoff. Run from
|
|
-- the sync compactor goroutine on a daily tick. Returns the number of
|
|
-- rows deleted so the worker can log meaningful progress.
|
|
DELETE FROM library_changes WHERE changed_at < $1;
|