Count the rows an ingest write actually changed - #51
Merged
Merged
Conversation
The apply run reported "wrote 935/935" and changed nothing. public.colleges is RLS read-only in normal operation, so the anon key's UPDATEs matched zero rows. PostgREST does not call that an error — an RLS-filtered update is a 204 with no error, exactly like one that succeeded — so the loop counted 935 accepted requests as 935 written rows. The database still held 46 regular-decision dates afterwards and not one row carried the new verified_at. So the write now asks for the changed rows back and counts those, and stops on the first that changed none rather than grinding through 935 silent no-ops. The message says what is actually wrong and what to do about it. scripts/ingest-colleges already documented the temporary anon write policy this needs, bracketing the run and dropped straight after; this one did not. Now it does.
--apply needs a policy letting anon update colleges, and anon is public in the JS bundle: for as long as it exists anyone can rewrite the table. A one-off annual write does not justify that window. emit-sql.mjs runs the same selection and writes no rows — it prints the changes as one statement to paste into the SQL editor, where it executes as the project owner. One statement, so it lands whole or not at all, and every column goes through coalesce(new, existing) so a curated value survives even if the selection were wrong. This is how the September 2026 run was applied: 935 rows, real regular-decision dates from 46 colleges to 977, with the 13 grid disagreements left for someone to settle by hand.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Deploying timeline-prototype with
|
| Latest commit: |
aa7fe06
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://3df44de9.timeline-prototype.pages.dev |
| Branch Preview URL: | https://fix-deadline-ingest-verifies.timeline-prototype.pages.dev |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The apply run reported
wrote 935/935and changed nothing.public.collegesis RLS read-only in normal operation, so the anon key's UPDATEs matched zero rows. PostgREST does not call that an error — an RLS-filtered update is a 204 with no error, indistinguishable from one that succeeded — so the loop counted 935 accepted requests as 935 written rows. The database still held 46 regular-decision dates afterwards and not one row carried the newverified_at.Two changes.
The write verifies itself
.select()on the update, so the changed rows come back and can be counted, and the loop stops on the first that changed none rather than grinding through 935 silent no-ops. The message names the cause and what to do about it.Applying goes through SQL run as the owner
--applyonly works bracketed by a temporary policy lettinganonupdatecolleges— and the anon key is public in the JS bundle, so for as long as that policy exists anyone can rewrite the table. A once-a-cycle write does not justify the window.emit-sql.mjsruns the same selection and writes nothing. It prints the changes as one statement to paste into the SQL editor, where it executes as the project owner:coalesce(new, existing), so a curated value survives even if the selection logic were wrong--applystays, with the RLS procedure now documented and the failure loud instead of silent.This is how the September 2026 run was applied
The 46 curated rows are untouched — Stanford still Jan 2, Georgetown still Jan 10, Wisconsin still Feb 1 — so the 13 places the grid disagrees are still there to settle by hand.
Parser tests: 8 passing, unchanged.