[Bug] UpdateConfig does not wake sandbox watchers after an atomic policy revision commit #2517

Agent Diagnostic

• Skills loaded: create-github-issue repository workflow
• OpenShell version tested: v0.0.91
• Latest release checked: v0.0.92; the affected atomic UpdateConfig path is unchanged
• Known fixes reviewed: current main at f00ad23a; other policy mutation paths notify the sandbox watch bus, but this path does not
• Possible duplicates reviewed: searched issues and pull requests for sandbox watcher, policy revision, same-policy, and notification terms; no matching report found
• Findings: an atomic configuration update can commit and return a new policy revision without waking the sandbox settings watcher
• Remaining reason for filing: the persisted desired revision advances while a connected sandbox can remain blocked waiting for a watch notification

Description

Actual behavior: UpdateConfig can persist a new sandbox policy revision in its atomic merge branch and return that revision successfully, but it does not call sandbox_watch_bus.notify. A watcher already subscribed for that sandbox receives no event. This differs from the non-atomic policy update and other policy mutation paths, which notify after persistence.

Expected behavior: every successfully committed sandbox configuration revision that can change the settings-poll result wakes connected watchers exactly once. Conflicting retries and failed writes must not notify.

Reproduction Steps

1. Store a sandbox with policy revision 1.
2. Subscribe to sandbox_watch_bus for that sandbox ID.
3. Call UpdateConfig with identical policy content and changed annotations/provenance, causing the atomic merge path to persist revision 2.
4. Confirm the response and stored policy report revision 2.
5. Observe that watch_rx.try_recv() returns Empty.

A focused server test can reproduce the failure by extending update_config_same_policy_hash_with_new_provenance_creates_revision with a watcher subscription and notification assertion.

Environment

• OS: Linux arm64
• Runtime: Kubernetes sidecar topology
• OpenShell: v0.0.91
• Latest release checked: yes, v0.0.92
• Possible duplicates checked: yes

Suspected Cause

handle_update_config_inner assigns the committed annotations immediately after the atomic retry loop, but does not notify the sandbox watch bus. The later standalone policy-persistence path does notify, so the atomic branch violates the same post-commit invariant.

Proposed Fix

Call state.sandbox_watch_bus.notify(&sandbox_id) immediately after the atomic commit succeeds and before subsequent response processing. Add a regression assertion that:

• subscribes before UpdateConfig;
• confirms the same-policy metadata change creates revision 2; and
• confirms the watcher receives a notification.

Logs

UpdateConfig response version: 2
stored policy version: 2
sandbox watcher: Empty