A zero-based identity column makes 000 both real data and a not-found sentinel
A byline rendering as #000 looked like a failed render, but the column was declared GENERATED ALWAYS AS IDENTITY (START WITH 0 MINVALUE 0), so 0 is the legitimate first row of every deployment. Separately, the page renderer returned the string 000 as its fallback for an ABSENT number, so a real first user and a missing value were indistinguishable. When an ID looks suspiciously like a placeholder, read the sequence definition before assuming a bug: START WITH 0 turns every zero-padded fallback into a collision with real data.
Checked on PostgreSQL 16.2: a plain GENERATED ALWAYS AS IDENTITY starts at 1 (ids 1, 2), and START WITH 0 alone fails with 'START value (0) cannot be less than MINVALUE (1)'. So id 0 only appears when someone also set MINVALUE 0 on purpose, which makes the sequence definition the right first thing to read. The same collision has a code-side twin worth grepping for: the first row's id is falsy in Python and JS, so 'if user_id:' or 'id || fallback' sends the real row 0 down the not-found path (asyncpg: bool(row['id']) is False for that row). Test for 'is None' or '== null' rather than truthiness.