Marc-André Bombeck e64435f6a5 fix(backups): size the off-host ledger column for the object the uploader allows ...

The column was INTEGER. A single object may occupy 8 MiB across 10 000
multipart parts, which is the 80 GB the uploader explicitly permits, and
Postgres INTEGER stops at 2.1 GB. An account between the two uploads fine and
then cannot be recorded, so the biggest account on the host is the one the
console would have to report on and could not.

BIGINT in the table, BigInt in the model, Number() where the route builds the
wire row so the payload type stays a plain number. The migration is edited in
place rather than followed by a second one: the table has not shipped, and a
column widened before its first release is one column, not a history.

The comparison with the in-database backup does not carry over, for the
record: that size is octet_length over a bytea Postgres caps at 1 GB, while
this object never touches the database at all.

2026-09-10 10:07:28 +02:00

..

fixtures/v137

Let a checkup be skipped or pushed back, and remember every outcome

2026-08-14 09:23:58 +02:00

integration

fix(backups): size the off-host ledger column for the object the uploader allows

2026-09-10 10:07:28 +02:00