[Bug]: 0.4.0 — observation capture wedges the session queue ("still settling" forever, reload deadlock) and action context expires before the next call #527

Activity

1. tom613951 commented on Oct 31, 2026

   

   tom613951

   on Oct 31, 2026

   More actions

   Additional reproduction: kind never converges from baseline on pages with a sub-10-second live region

   Reporting a narrower trigger than a TTL expiry, measured on bsk 0.4.0 / extension 0.4.0 / protocol 1.7, Windows + Chrome 156.0.0.0, local browser (no remote WSS gateway). Both defects reproduce.

   Environment

   daemon_version     0.4.0
   protocol_version   1.7
   extension_version  0.4.0
   chrome             156.0.0.0
   host               Windows, local browser (no WSS gateway)
   

   observationEnabled was true at first, then set to false in the DSH plugin config. Toggling it did not change CLI-side behaviour, which is consistent with the capture path living in the extension rather than the plugin.

   Controlled A/B on one session

   Two pages, one daemon, one session (zhwp), bsk cooperate sync repeated 6× at 1.2 s intervals. Identical harness both times.

   A — https://example.com (static):

    i   rev       kind      ms  delta
    0     9   baseline      90
    1    11  unchanged      19  +2
    2    13  unchanged      19  +2
    3    15  unchanged      20  +2
    4    17  unchanged      19  +2
    5    19  unchanged      19  +2
   

   baseline on the first capture only, then unchanged. Actions succeed:

   0: OK value=4
   1: OK value=4
   ...
   5: OK value=4
   --- ok=6 fail=0
   

   B — https://bbs.huaweicloud.com/blogs/article (same session, after navigate):

    i   rev       kind      ms  delta
    0    91   baseline    1133
    1    95   baseline    1128  +4
    2    99   baseline    1131  +4
    3   104   baseline    1104  +5
    4   108   baseline    1124  +4
    5   112   baseline    1080  +4
   

   baseline on every capture, never unchanged. Every action refused:

   0: REFUSED The action's observed content changed; s
   ...
   --- ok=0 fail=6
   

   Two stable differences: kind never leaves baseline, and sync costs ~1100 ms instead of ~20 ms — a ~55× increase, consistent with a full VOM capture each call rather than an incremental comparison.

   What the page does

   The editor renders a live autosave counter in its footer — "21 秒后保存", "4 秒后保存", counting down and resetting on a sub-10-second cadence. That counter sits inside the editor's form container. PR #497 deliberately keeps form values, checked state, modals and the action's own region exact, and the <main>/landmark relaxation excludes positioned panels, so a counter inside the form container is never learnable as volatile. The result is that this page cannot reach unchanged at all.

   --depends-on does not help, because the refusal happens on the whole-page capture before target scoping:

   $ bsk evaluate --session <sid> --context <ctx> \
       --depends-on "input.write-blog-blog-title" --json "(()=>1)()"
   {
     "code": "permission_denied",
     "message": "The action's observed content changed; synchronize and replan"
   }
   

   Session state also degrades

   An earlier session (opyq) showed unchanged on example.com at first, then began returning baseline on the same unchanged page after roughly 20 minutes of repeated sync/refuse cycles — after which example.com was refused 6/6 as well. A brand-new session restored unchanged immediately. So there appear to be two independent ways to lose convergence:

   1. a page with an unlearnable live region inside a protected container, and
   2. accumulated session state, which stops converging even on a static page.

   Defect A, as observed

   After several refusals the session wedges, matching your report:

   $ bsk cooperate sync --session <sid>
   error: shared page control or observation changed
   details: Could not establish connection. Receiving end does not exist.
   

   The details line is a content-script messaging failure, not a cooperation refusal. bsk reload cannot recover it because reload needs a context from the sync that just failed. bsk session stop --all is the only exit. Reproduced on about:blank and on example.com after a daemon restart; cleared by a fresh session followed by bsk cooperate wait.

   Not reproduced

   state in this build carries only editing, mode, revision — there is no target and no target.expires, so I could not reproduce the specific expires-not-renewed path. Everything above is the baseline-never-settles path.

   Suggested narrowing

   The case worth isolating is live text inside a form/list/dialog/panel versus live text in a plain container. The first appears to guarantee a permanent baseline. It may deserve either an escape hatch, or a documented note that such pages require a --depends-on naming a container outside the live region — the current docs advise omitting --depends-on when unsure, which is exactly the state that cannot recover here.

   Happy to re-test against main once #529 ships in a release and report whether the baseline case persists.
2. MoyuP commented on Oct 31, 2026

   

   MoyuP

   on Oct 31, 2026

   More actions

   DSH plugin data point: the "still settling" refusal is not recoverable from DSH either

   macOS arm64, local Chrome, bsk/extension/DSH plugin 0.4.0, DSH desktop 0.2.1-rc.5.

   Sequence: bsk_session start OK → bsk_page navigate OK (reached: load) → first bsk_session sync fails 3/3 with "Previous operation is still settling; this action was not dispatched". settle: true fails identically. Sleeping ~5 s and syncing once succeeds; screenshot and stop are clean afterwards.

   0.4.0 mechanism (from source):

   • cooperation sync bypasses the plugin's per-session queue, while the observation thumbnail screenshot runs inside it. Every tool call first calls acquireForeground, which kills the running observation:... screenshot. The sync then reaches the extension while it is still settling the cancelled capture, so the dispatcher returns cdp_failed (apps/extension/src/tools/dispatcher.ts, "Previous operation is still settling; this action was not dispatched").
   • Retrying makes it worse: on release, ObservationService.acquireForeground schedules a new thumbnail immediately (scheduleCapture(..., 0)), which the next retry preempts again. That matches 3/3 immediate retries failing and one ~5 s wait succeeding.
   • --settle cannot help: crate::cli::cooperate::settle::recoverable only retries permission_denied + cooperation_sync_required + effect_state: none; this refusal is cdp_failed / dispatched: false, so settle returns on the first attempt without ever calling cooperate wait.
   • The suggested recovery is unreachable: reload is a shared action and requires the latest sync context, so sync-fail → no context → reload refused. cooperate wait (DSH: bsk_session action:"wait-user") is the closest native equivalent, but it is named and described for hand-back, not for this recovery.

   Even on main (1b395fd) the settle predicate, the cdp_failed hint and the context gate are unchanged, so #529 fixes the ordering trigger but not this recovery path.

   Suggestions:

   1. In settle::recoverable, also retry the transient cdp_failed + data.dispatched === false "still settling" refusal with a bounded wait, or surface it as session_busy so the DSH plugin's runWithSessionBusyRetry applies.
   2. Do not suggest reload for this condition (it is context-gated). Suggest waiting for the session to settle and syncing again, and/or expose an explicit wait/recovery action in DSH instead of only wait-user.
   3. Document that 0.4.0 thumbnail captures can collide with the first sync, and that "brief wait, then sync" is the safe retry.

   Happy to re-test against the next release.