VersionControl:PRs/rabbithole/16: Difference between revisions

From PickiPedia: A knowledge base of bluegrass, old time psychedelic jams, and other public domain music
Jump to navigationJump to search
DrivingThatTrain (talk | contribs)
cryptograss/rabbithole#16, as GitHub has it
DrivingThatTrain (talk | contribs)
cryptograss/rabbithole#16, as GitHub has it
 
(One intermediate revision by the same user not shown)
Line 5: Line 5:
|url=https://github.com/cryptograss/rabbithole/pull/16
|url=https://github.com/cryptograss/rabbithole/pull/16
|author=magent-cryptograss
|author=magent-cryptograss
|state=open
|state=merged
|base=main
|base=main
|branch=fix/pane-latest-wins
|branch=fix/pane-latest-wins
|opened=2026-11-06 07:52:25
|opened=2026-11-06 07:52:25
|pushed=2026-11-06 08:00:36
|pushed=2026-11-06 08:00:36
|merged=
|merged=2026-11-06 17:09:20
|closed=
|closed=
|worked_on_by=magent, skyler, justin
|worked_on_by=magent, skyler, justin
Line 16: Line 16:
|deploy=
|deploy=
}}
}}
<pre class="pr-body">Audit item 2. Two solo changes in a row fetched two wiki pages and the slower one won; the "already here" check then refused the right page because its title was already recorded.
**The rule:** the pane shows the page most recently asked for.
**By construction:** each `openWikiPage` aborts the request before it (AbortController) and becomes the newest; a response checks it is still the newest before touching the pane or the history, and is dropped otherwise. The abort signal goes into both fetches, the parse call and `paneBody`'s article fetch, so a superseded request downloads nothing more. The pane records what was asked for (`wikiWanted`) apart from what is on screen (`wikiTitle`): a repeat of a page already on its way is a no-op, and a page that failed for real is forgotten so a retap tries again.
**Checked** on pickipedia.xyz with the branch routed in and Maddie Denton's requests held back 2s: tap Maddie, then Justin 150ms later. The pane shows Justin at once and stays on Justin; Maddie's parse request ends `net::ERR_ABORTED` and her body fetch never starts. Wiring tests cover the abort, the signal in both fetches and the drop; 91 pass.
Redeploy: pickipedia
Worked on by: magent, Skyler, Justin, in #rabbithole</pre>

Latest revision as of 18:06, 9 November 2026

rabbithole#16: Pane: the page most recently asked for is the one shown
State 🟣 merged 2026-11-06 17:09:20
Worked on by magent, skyler, justin
Moods #rabbithole
Deploy not said
Branch fix/pane-latest-wins → main, by magent-cryptograss
Opened · last pushed 2026-11-06 07:52:25 · 2026-11-06 08:00:36
Audit item 2. Two solo changes in a row fetched two wiki pages and the slower one won; the "already here" check then refused the right page because its title was already recorded.

**The rule:** the pane shows the page most recently asked for.

**By construction:** each `openWikiPage` aborts the request before it (AbortController) and becomes the newest; a response checks it is still the newest before touching the pane or the history, and is dropped otherwise. The abort signal goes into both fetches, the parse call and `paneBody`'s article fetch, so a superseded request downloads nothing more. The pane records what was asked for (`wikiWanted`) apart from what is on screen (`wikiTitle`): a repeat of a page already on its way is a no-op, and a page that failed for real is forgotten so a retap tries again.

**Checked** on pickipedia.xyz with the branch routed in and Maddie Denton's requests held back 2s: tap Maddie, then Justin 150ms later. The pane shows Justin at once and stays on Justin; Maddie's parse request ends `net::ERR_ABORTED` and her body fetch never starts. Wiring tests cover the abort, the signal in both fetches and the drop; 91 pass.

Redeploy: pickipedia
Worked on by: magent, Skyler, Justin, in #rabbithole