1d0df3ebf6
The ordinary mobile failure, not an exotic one: the server receives the body, validates it, commits the row — and the response is lost on the way back because the guest walked out of range or the AP dropped the connection. The client sees a network error with the blob still in hand and re-sends it, both when the guest taps "Erneut" and automatically when the queue requeues on reconnect. Every attempt minted a fresh `Uuid::new_v4()` server-side, so the same photo landed in the gallery two or three times and was charged against the guest's storage quota each time. The client already has a stable per-queue-item UUID, so it costs nothing to send. Migration 022 adds `client_upload_id` with a partial unique index — partial so the NULLs of every pre-022 upload, and of any caller that doesn't send one, keep working untouched. Two paths, because there are two races: - Sequential retry: a lookup before the transaction finds the stored row, deletes the re-sent bytes and replays the original response as 200. The body has necessarily already been streamed, since the key arrives as a multipart field — re-sending is the client's cost and is already paid by the time we see it. What must be prevented is a second ROW. - Concurrent retry: two attempts in flight at once. `ON CONFLICT DO NOTHING` returns no row to the loser, which abandons its transaction (quota increment included) and replays the winner. Letting the unique index raise instead would only surface after the transaction had aborted, as an opaque error the caller would have to string-match. The replay reads live state rather than assuming a fresh row: a reconnect can be minutes later, by which time the derivatives may exist and the photo may have been liked. Every read there fails soft — the upload is already safely stored, so a sparser response is fine and failing the request is not. Verified live: the same photo sent three times returns 201, 200, 200 with one id, one row, and the quota charged exactly once. Also in this file: the two image-header probes at admission now run on `spawn_blocking`. Both open the file and run the codec's header parse synchronously, and `#[tokio::main]` gives two worker threads on a 2-vCPU box — so every upload stalled half the runtime's request-serving capacity. Everything else that blocks here (image encode, bcrypt) was already offloaded; this was the one that wasn't. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
26 lines
1.6 KiB
SQL
26 lines
1.6 KiB
SQL
-- Idempotency key for uploads, supplied by the client.
|
|
--
|
|
-- The failure this closes is the ordinary one on a phone, not an exotic race: the server
|
|
-- receives the body, validates it, commits the row, and the response is lost on the way back
|
|
-- because the guest walked out of range or the AP dropped the connection. The client sees a
|
|
-- network error with the blob still in hand, marks the item retryable, and re-sends it — both
|
|
-- when the guest taps "Erneut" and automatically when the queue requeues on reconnect. Every
|
|
-- attempt minted a fresh `Uuid::new_v4()` server-side, so the same photo landed in the gallery
|
|
-- two or three times and was charged against the guest's storage quota each time.
|
|
--
|
|
-- The client already has a stable per-queue-item UUID, so it costs nothing to send. NULL is
|
|
-- allowed and unconstrained: uploads that predate this column, and any client that doesn't send
|
|
-- one, keep working exactly as before.
|
|
ALTER TABLE upload ADD COLUMN client_upload_id UUID;
|
|
|
|
-- Partial rather than a plain UNIQUE. Postgres would tolerate the NULLs either way, but indexing
|
|
-- only the rows that carry a key keeps it small and states the rule exactly: uniqueness applies
|
|
-- where a key exists, and nowhere else.
|
|
--
|
|
-- Scoped globally rather than per user or per event. The key is a client-generated v4 UUID, so a
|
|
-- collision between two different photos is not a real possibility, and a single-column index
|
|
-- means the uniqueness check cannot be wrong about which event or user a retry belongs to.
|
|
CREATE UNIQUE INDEX upload_client_upload_id_key
|
|
ON upload (client_upload_id)
|
|
WHERE client_upload_id IS NOT NULL;
|