Staff engineer @ Tenable. Ex-Microsoft, production AI agents. Now solo on an AI-native fitness app. Agents, MCP, Postgres, and the numbers I'd rather not post.
6/ Nobody reported it. It came off a review pass my clanker ran over that whole wave, as item A on the list.
The rule I keep now: a keyset cursor has to be exactly as unique as the ORDER BY it pages on. A batch insert makes a timestamp non-unique on purpose.
Page two of my recents list came back empty, so the list stopped.
It was not empty. Thirteen rows were sitting behind the cursor, and every one of them had been written by the same insert. π§΅
5/ The fix is one tuple: (last_logged_at, item_id) < (p_before, p_before_id), and the cursor sends both halves or neither.
The ids are UUIDv7, so they are already time ordered. The tie break costs nothing and adds no second sort column.
The fix made the tests slower. Four turbo tasks by three vitest workers: twelve processes on ten cores, and room for the clanker session that pushed.
If CI lives on a box you own, the question is not how many cores the tests get. It is who else is alive there.
My CI gate printed ALL CHECKS PASSED and GitHub marked the job failed.
Three pushes in a row, and nothing shipped from any of them.
The tests were right. The runner was right. GitHub was right. The job died of a missed heartbeat.
The same starvation had shown up earlier as a different lie: full-page component tests timing out at 5s, three gates in a row, every one passing alone.
I nearly tagged them flaky. A starved worker crosses a timeout without a single test being wrong.