Regression: extension does not reconnect after a manual daemon restart (logs stay silent for 11+ minutes) #395

Activity

1. galaxy42948

   changed the title [-]重启后台服务后，浏览器扩展不会自动重连[/-] [+]Browser extension does not reconnect after a manual background service restart[/+] on Oct 5, 2026
2. galaxy42948

   changed the title [-]Browser extension does not reconnect after a manual background service restart[/-] [+]Regression: extension does not reconnect after a manual daemon restart (logs stay silent for 11+ minutes)[/+] on Oct 5, 2026
3. CHENZlHAO commented on Oct 13, 2026

   

   CHENZlHAO

   on Oct 13, 2026

   More actions

   Hi! I'd like to investigate this issue as my first contribution to BrowserSkill.
   I'll start by trying to reproduce the reconnect failure and checking the extension's connection lifecycle and existing tests. My local environment are macOS and windows, so I'll also check whether the behavior occurs in MACOS
   If I can reproduce the problem, I'd like to submit a focused fix with a regression test. Is anyone already working on this, or is there any related work I should coordinate with?
   Thanks!
4. galaxy42948 commented on Oct 13, 2026

   

   galaxy42948

   on Oct 13, 2026

   Author

   More actions

   Hi @CHENZlHAO, thanks for picking this up -- as far as I can tell nobody has claimed it yet, so you're clear to take it.

   I can help with Windows-side data. My environment (the one in the report above): bsk 0.3.2 on Windows 11, Edge + the official extension. What I can provide:

   • Daemon logs across a full manual restart cycle (daemon ready -> extension reconnect), including the silent window;
   • Exact bsk / Edge / OS build numbers;
   • Whether the extension makes any reconnect attempt at all, or stays fully silent.

   One extra data point from my host: here the daemon can't auto-start from a client command -- Windows Job Object breakaway is blocked (os error 5), so it has to run as bsk daemon start --foreground in a persistent host task. Different symptom from yours, but it suggests the Windows daemon lifecycle has more edge cases worth covering in tests.

   What would be most useful from my side? Happy to run any repro steps and paste raw logs.
5. CHENZlHAO commented on Oct 14, 2026

   

   CHENZlHAO

   on Oct 14, 2026

   More actions

   Hi @galaxy42948, I tested Windows + Edge with bsk 0.3.2 and the official 0.3.2 release ZIP loaded unpacked. My Edge version is 155.0.4283.45 and Windows is 25H2, build 26200.9457.

   I ran three foreground-daemon Ctrl+C restart cycles with measured offline intervals of about 73, 45 and 120 seconds. With no active sessions and the extension popup and service-worker DevTools closed, the extension reconnected automatically 1.58s, 0.25s and 8.46s after daemon-ready. It remained responsive for at least two minutes in each run. I captured the console logs, status snapshots and screenshots, but haven't reproduced the prolonged failure yet.

   This used a newly installed unpacked extension and an isolated daemon home, so it doesn't cover your long-running setup or establish that the issue is resolved. Could you share your exact builds, installation source, restart method and host, whether there were active sessions or sleep/lock events, and logs spanning the stop/restart? Please also include the logging configuration, since this host inherited RUST_LOG=warn and I had to set it to info to capture the ready/connected events.
6. galaxy42948 commented on Oct 14, 2026

   

   galaxy42948

   on Oct 14, 2026

   Author

   More actions

   Hi @CHENZlHAO, thanks for the thorough testing. Here is the data from my host -- this is the same machine the original report came from, so the 11-minute window is in my daemon logs with exact timestamps.

   Environment (exact builds)

   • bsk 0.3.2, installed manually from the GitHub release asset bsk-v0.3.2-x86_64-pc-windows-msvc.zip (sha256 verified), unpacked to ~/.local/bin/bsk.exe, user PATH updated.
   • Windows 11, build 26300.9550 (newer than your 25H2 / 26200.9457).
   • Edge 155.0.4283.45 (same as yours; 154.0.4258.62 also installed side by side).
   • Extension: installed from the Edge Add-ons store, NOT unpacked -- a difference from your test setup.
   • BSK_HOME: default (C:\Users<user>.bsk) with daily-rotated daemon.log. files. This is a long-running home with weeks of history, not an isolated one.
   • Logging config: RUST_LOG is not set on this host; the daemon logs at INFO by default, which is how the ready/connected events below were captured. No extra configuration was needed here.

   Daemon lifecycle on this host

   The daemon runs as a long-lived background service, started by hand with bsk daemon start --foreground in a persistent host task. Auto-start from client commands is blocked on this host (Windows Job Object breakaway restriction, os error 5), so every start in the logs is a manual foreground start -- no Ctrl+C cycles, no isolated daemon home. Startup lines read "background":false,"in_job":"Ok(true)".

   The repro window (daemon.log.2026-10-05, all timestamps UTC)

   00:07:29.895  Windows daemon process started, pid 37912, background:false
   00:07:30.075  daemon ready, pid 37912, ws_port 52800
   00:07:30.076  ipc named-pipe server listening
   00:07:30.088  WARN skill auto-update paused (local changes detected)
   00:18:34.687  browser connected, id fa499c7d, name edge, generation 1
   

   11m04s of complete silence between ready and connected, and the connect only happened after I toggled the extension off/on in its popup (as described in the original report). No failed handshake, no reconnect attempt logged in between -- the same silence you are looking for.

   Context around that restart

   • The previous daemon (started 10-04 08:40 UTC) stopped logging at 10-04 10:40 UTC with NO shutdown line -- abrupt death. Its periodic update checks (30-60 min cadence while running) also stop dead there, and on this host a locked session does not suspend processes, so the 13.5h log silence that follows indicates sleep/hibernate or full shutdown. Edge had been open (the extension was connected right up to the daemon death).
   • A contrasting case the same day: after the 09:07 UTC daemon died the same silent way, I restarted at 14:26:32 UTC and the extension reconnected in 4.3 seconds with no user action at all.
   • More contrasts: 10-03, 25 min downtime -> reconnect in 23s; 10-03, 3.2h downtime -> 3s.

   Full dataset: ready -> first-connect gap for every fresh daemon start (Oct 1-13)

   10-01 16:08:46 -> 16:10:44   1m58s
   10-02 03:35:44 -> 03:35:53      9s
   10-02 16:29:51 -> 16:29:51      0s
   10-03 00:07:26 -> 00:07:49     23s
   10-03 03:19:30 -> 03:19:33      3s
   10-03 04:55:35 -> 04:55:36      1s
   10-03 05:23:54 -> 05:23:54      0s
   10-04 05:03:22 -> 05:03:26      4s
   10-04 08:40:27 -> 08:40:36      9s
   10-05 00:07:30 -> 00:18:34   11m04s   <-- the reported bug
   10-05 14:26:32 -> 14:26:36      4s
   10-10 07:05:22 -> 07:05:25      3s
   10-10 07:24:03 -> 07:24:08      5s
   10-10 11:38:53 -> 11:38:57      4s
   10-12 13:00:15 -> 13:00:15      0s
   

   15 of 16 restarts reconnect in under 2 minutes (most under 10s); the single outlier is the reported one. Correlation so far: downtime <= 5.3h reconnects in seconds; the 13.5h downtime produced 11 minutes of silence. Small sample, but the long-downtime angle may be worth isolating in your repro -- e.g. overnight sleep cycles with Edge left open, versus your 73/45/120s intervals.

   Sessions and sleep/lock

   • At the time of the pathological restart there were NO live sessions (the last one had been idle-stopped 14.5h earlier). Sessions were started only after the reconnect. Same for the 4.3s case.
   • The daemon log cannot distinguish sleep vs shutdown vs lock directly; as noted above, lock does not suspend processes on Windows, so the multi-hour silences are sleep/hibernate or shutdown. I can pull the Windows event log (Kernel-Power 42/107) if that would help.
   • One more pattern that may be relevant: three times the extension reconnected within ~0.3-1.5s of the daemon's idle-threshold exit (10-01 23:44:04, 10-05 23:51:40, 10-13 00:05:27; the latter two right after machine wake) -- i.e. the extension's retry loop was demonstrably alive and aggressive in those windows. In the pathological window it was not retrying at all.
   • Also: on 10-05 and 10-12 the idle-exit fired 6-8h after the browser disconnect instead of the configured 600s, consistent with the idle timer not advancing across sleep.

   Unknowns I cannot answer from the logs

   • Whether Edge was closed and reopened (versus left running) around the overnight sleep before the pathological restart. I believe it was left running, but I cannot prove it from the daemon side.
   • The exact shell/host the manual bsk daemon start --foreground was issued from at 00:07 UTC (a terminal on this machine; the log only shows foreground and in-job).

   Offer

   I can run controlled restart cycles on this host -- downtime varied from minutes to overnight sleep, extension untouched, RUST_LOG=info, full logs and status snapshots captured -- whenever you want another data point. Just tell me what to vary.

   Note: the periodic update check failed WARN lines in my logs are this host's network situation (github.com unreachable from the daemon's egress) -- environmental noise, presumably unrelated to the reconnect issue.
7. CHENZlHAO commented on Oct 18, 2026

   

   CHENZlHAO

   on Oct 18, 2026

   More actions

   Thanks again for your help. I’m continuing to work toward a fix for #395.
   Since I haven’t reproduced the prolonged reconnect failure locally, I’ve opened draft PR #460 with the investigation results and opt-in extension diagnostics. The diagnostics are intended to capture the missing extension-side evidence during a failure, so we can identify the root cause and develop a targeted fix.
   This is a step toward resolving #395; the reported failure is not fixed yet. I’m validating the new diagnostic controls locally in Edge, so there’s no additional testing needed from you at this stage. Thanks again for the information you’ve already provided.
8. galaxy42948 commented on Oct 18, 2026

   

   galaxy42948

   on Oct 18, 2026

   Author

   More actions

   Thanks for the deep investigation and for opening #460 -- I have now read the full PR and the investigation record. The recorder covers exactly the blind spots in my daemon-side dataset: controller.request with its gate field separates "no request arrived" from "request blocked by transition/cleanup/handshake-retry", alarm.tick/alarm.skipped show whether the keepalive loop was even running, and the socket lifecycle events separate an outstanding attempt from no attempt at all. My pathological window is pure silence in the daemon log, so any of those outcomes would be new information.

   One scenario gap worth keeping on the list: my single outlier followed ~13.5 h of daemon downtime with Edge left running and no active sessions. Your overnight cycle (daemon exited ~75 s after resume) does not isolate "daemon absent all night while the browser stays open", so that combination is still untested on both sides.

   When you are ready for report-environment data, I can load the diagnostic build on this host (store extension, weeks-old daemon home, same Edge 155.0.4283.45 / Windows 26300.9550), enable recording, run controlled restart cycles including an overnight one, export the snapshot before toggling the connection or opening worker DevTools, and correlate it with daemon logs. I will keep the unpacked-ID / fresh-storage difference explicit as your doc asks.

   Two things from my dataset the recorder could confirm directly:

   • On three occasions the extension reconnected ~0.3-1.5 s after the daemon's idle-threshold exit, so the retry loop was demonstrably alive in those windows. alarm.tick events around an idle-exit during a failure window would show whether that liveness is present or absent.
   • On 10-05 and 10-12 the idle-exit fired 6-8 h after the browser disconnect instead of the configured 600 s, consistent with the idle timer not advancing across sleep. alarm.skipped gaps across a sleep would be a second data point for that clock behavior.

   No rush from my side -- happy to wait until your local validation of the controls is done, or to build from your fork earlier if a report-environment run would help in parallel. Just tell me which build to load and what to vary.