The account row is fixed, and the post's own headline was wrong when it published - #92
Merged
Merged
Conversation
…was wrong when it published The corrections post went live at 01:03 on 25 August saying one row was still open. It was not: the site had been republished with its database configuration at 17:44 the afternoon before. The sentence was typed rather than read off the registry, so it could not have been anything else. Three things change. The account row is fixed, and its date was wrong too. It said 3 August on the reasoning that we could not see which earlier builds carried the configuration from outside. We can: every deployment this repo publishes keeps a permanent address, and the ones from 9, 14 and 15 August all carry it. The fault was never a missing variable. Something other than this repository's deploy published to playpip.io on 23 August without the configuration, over a build that had it, and the workflow's next deploy on 24 August put it back. One day, not twenty-one. That row is fixed but keeps its sentence, because the words were right and the product was missing, so 'gone' would ban the thing we now want to go on saying. New field, fixedInProduct, and the test knows the difference between that and a row nobody finished. It also has no guard and says so in the page rather than in a comment: assert-sync-config.mjs can only read a build made by the deploy it is attached to, which is not the deploy that went wrong. The post's claim about its own open rows is now read off the registry at build time, pinned by a test, and the stale sentence is row eight.
Deploying pip-web with
|
| Latest commit: |
80a6acb
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://0f46d54c.pip-web-9oj.pages.dev |
| Branch Preview URL: | https://fix-corrections-account-row.pip-web-9oj.pages.dev |
The row said "something other than this repository's deploy" published playpip.io on 23 August. It has a name now: a hosting-side Git integration connected to the same Pages project, which builds every push without the test gate and without the NEXT_PUBLIC_SUPABASE_* variables the deploy workflow supplies. Confirmed from outside, no dashboard needed: its build of 81d9e93 is still at c529ed3e.pip-web-9oj.pages.dev, it stamps pip-81d9e93, it carries no supabase.co literal, and it carries the env.NEXT_PUBLIC_SUPABASE runtime lookup that is the fault signature. guardNote follows: the fix that holds is one publisher, which is a hosting setting, not a line in this repository.
This was referenced Aug 26, 2026
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 post about our false claims published with one in it
/blog/what-we-got-wrongwent live at 01:03 on 25 August saying "One of them isstill wrong as this goes up." It was not. The site had been republished with its
database configuration at 17:44 the afternoon before, seven hours earlier. The
sentence was typed rather than read off the registry the rest of the page is generated
from, which is the only way it could have gone stale.
The account row is fixed, and the date it printed was wrong too
The row said 3 August, on the stated reasoning that we could not see from outside
which earlier builds carried the configuration. We can, and I should have looked before
writing a date down. Every deployment this repository publishes keeps a permanent
address, and I read the bundle out of three of them:
5e4ccbdb75d782b8fb731060ed2a7e26(#86)691e7918(#87)Every build this workflow has ever made had the variables in it. The repository
variables were never missing, and setting them was never the fix.
What actually happened is narrower and worse. The deploy workflow's run for
81d9e93on23 August failed at the security-audit step and skipped build and publish, so this
workflow published nothing between 15 Aug 09:48 and 24 Aug 16:44. Yet the live
site on the morning of 24 August was carrying the nine merges from 23 August, and the
15 August build still serves
your profile never leaves your deviceat its permanentaddress today. Something other than this workflow published to playpip.io on 23
August, and whatever it was built without the configuration.
Live now, verified from outside this morning rather than assumed:
2bgg_makkgv9r.js, no runtime lookup in anything the site referenceshttps://gjzwwlffeygxtkxavfau.supabase.co/auth/v1/settings-> 200, email sign-up enabled/rest/v1/profiles-> 200[]anonymously;/rest/v1/memberships-> 404, still absentSo the row is 23 to 24 August, one day, not twenty-one.
Three schema changes, each because a row would otherwise have to lie
fixedInProduct. The words on/privacywere right and the product was missing, sothe fix was a deploy, not an edit.
gonehas to stay null: banning a fragment of thatsentence would ban the sentence we now want to go on saying. Previously the test demanded
a
goneon every fixed non-post row, so the only way to record this row was to inventone.
guardNote. A fixed row names the test that stops it recurring or says in the pagewhy there is none. This row has none.
scripts/assert-sync-config.mjscan only inspecta build made by the deploy it is attached to, and that is not the deploy that went wrong.
It is also still not wired into any deploy: neither AI can push
.github/workflowswithout the
workflowspermission, and I confirmed that by trying (refusing to allow a GitHub App to create or update workflow).The post's live state is computed.
open.lengthdrives the intro paragraph, so thepage can no longer disagree with its own list.
tests/corrections.test.tspins that andfails if
as this goes upcomes back.Row eight is this post
corrections-post-open-rowis open, deliberately. A merge is the deploy, so thestale sentence is serving until this lands and I do not know the date that will happen
on. The next session sets its
fixedOnto the merge date, and the existing"a corrected post carries its correction note" test will fail until a
<Correction>notegoes under the title, which is the right forcing function.
Gate
pnpm test:allgreen, 474 tests,pnpm buildclean, biome-formatted. The audit lineis the pre-existing moderate advisory, unchanged, no highs.