store

const FileLiveSQL = `(expires_at IS NULL OR expires_at > now())`

FileLiveSQL is the predicate that says a files row still has content: it has no expiry, or its expiry has not arrived (#655, plan 49). Here for SessionTombstoneInsertSQL's reason, and more urgently.

Four packages read this table to hand a file's bytes to something — api, brain, executor, events — and each was written when a row's existence was the whole question. When the expiry rule arrived, only api's own route was taught it; the other three were found serving expired bytes in review, one of them mounting into a sandbox what the HTTP route was already refusing. So the rule is written once, here, rather than in each reader's SQL: a reader that composes it has agreed to it, and a reader that does not has decided something instead of forgetting it.

It reads now() from the database, never a replica's clock: expires_at was computed from the database's now() at upload. Unqualified, so it composes into a query that aliases the table as well as one that does not.

now() is transaction start, not statement time, so a transaction that began just before an expiry and then waited on a row lock still sees the file as live. That is the wanted reading rather than a gap clock_timestamp() would close: a create mounting ten files judges all ten against one instant instead of letting the tenth expire between statements, expires_at is itself a now() value, and every other age predicate in this platform compares against now(). The residue is a sub-transaction race that no clock function wins — a client one microsecond earlier would have been admitted anyway.

One reader deliberately omits it, and only one: the grader's deliverables listing (internal/brain/grader.go) selects `scope_type = 'session'` rows, which only the outputs harvest writes, and the harvest sets no expiry — the upload route is the one writer that can. Composing it there would guard a state no writer can reach.

const PendingObjectDeleteInsertSQL = `INSERT INTO pending_object_deletes (object_key)
	 SELECT unnest($1::text[])
	 ON CONFLICT (object_key) DO NOTHING`

PendingObjectDeleteInsertSQL enqueues object keys the caller's transaction has just orphaned, for the sweeper that deletes them (plan 50). One definition on the schema's owner for the same reason as the tombstone above: the producer and the consumer are in different packages and must agree on the shape exactly.

One statement for the whole set, because a session's deliverables are up to two hundred keys and a delete should not become two hundred round trips inside a transaction that holds the session row. Conflicts are ignored: an object already owed is owed once, and a key enqueued twice would otherwise fail a delete that has nothing wrong with it.

const SessionTombstoneInsertSQL = `` /* 184-byte string literal not displayed */

SessionTombstoneInsertSQL writes a session's deleted_sessions tombstone — id and environment kind, read while the sessions row can still be joined, so it must run before the DELETE in the same transaction. One definition on the schema's owner: the API's deleteSession executes it in production and the reaper's tests use it to stage deleted sessions, so the shape the reaper consumes cannot drift from the shape the API writes (the tombstone is the reaper's deleted-tier evidence — plan 24).