fix(launch): the installed app opens to the house, not to "Scan code" - #9
Conversation
Two faults, either of which alone sends a paired device to the pairing screen. Together they made the home-screen app almost unusable. The launch probe built the database, empty. index.html opens 'ftw' at version 1 before the bundle parses, to paint the last readings in the first frame. When no database exists that open CREATES one — at version 1, with no object stores, because the probe's upgrade handler only wanted a snapshot. So db.ts, opening the same name at the same version, gets no upgrade callback and creates no stores. Every read and write is then broken for the life of the install: nothing can be paired, nothing can be read back, and the app can only offer to pair again. Aborting the upgrade transaction undoes the creation, so the app's own open is the one that builds the schema. The launch pointer lived only in localStorage. It is a hint, not the record — the record is the 'sites' store — but a missing hint was treated as "not paired". An installed PWA on iOS does not inherit the browser tab's localStorage, so the first standalone launch had no hint and showed the pairing screen for a house that was already paired, with a code the box would rightly refuse. The launch now falls back to the database and rewrites the hint from it. The pairing screen no longer flashes while that lookup runs. It is a large, decisive screen and showing it on a guess is worse than the bug it replaces; the shell paints as always and only the content area waits, for a local read. Verified in a browser: with the hint deleted and the app reloaded, it recovers the site, restores the hint, and paints the house. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
ftw-webapp | 9ff9392 | Aug 05 2026, 05:29 PM |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9ff939243f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| resolvingSite = false | ||
| } | ||
| if (!recovered || siteId) return | ||
| siteId = recovered |
There was a problem hiding this comment.
When localStorage is missing but IndexedDB still has the paired site, restoring a saved /p#... URL leaves pairingFragment set to the raw fragment because the existing fragment check only runs when initialSiteId was present. In that scenario this recovery path sets siteId, starts/connects the site, but the template still prioritizes pairingFragment and mounts Pair, whose effect immediately tries to spend the fragment again; a freshly installed/restored PWA can therefore still show the stale pairing error instead of going home. The recovered site should be run through the same fragmentTarget logic, or clear the fragment when it targets the recovered site.
Useful? React with 👍 / 👎.
1 participant
Two faults, either of which alone sends a paired device to the pairing screen.
1. The launch probe built the database, empty
index.htmlopensftwat version 1 before the bundle parses, so a warmlaunch can paint cached readings in the first frame. When no database exists,
that open creates one — at version 1, with no object stores, because the
probe's
onupgradeneededonly ever wanted a snapshot.db.tsthen opens the same name at the same version, gets no upgradecallback, and creates no stores. Every read and write is broken for the life
of the install. Nothing can be paired, nothing read back — the app can only
offer to pair again, forever.
Reproduced in a test that drives both opens in launch order: the app's
upgradedflag isfalseandobjectStoreNamesis empty. The fix aborts theupgrade transaction, which undoes the creation.
2. The launch pointer lived only in localStorage
It is a hint; the record is the
sitesstore. But a missing hint was readas "not paired" — and an installed PWA on iOS does not inherit the browser
tab's localStorage, so the first standalone launch had no hint and offered
to pair a house that was already paired, with a code the box would rightly
refuse.
The launch now falls back to the database and rewrites the hint from it.
And no flash
The pairing screen is large and decisive; showing it on a guess for one frame
is worse than the bug. The shell paints as always — only the content area
waits, and only for a local read.
Verified
In a browser, with the hint deleted and the app reloaded: the site is
recovered, the hint restored, and the house painted.
showsPairing: false.Full suite: 340 passing.