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

[NaveCohenMonday]

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

[drew]

📋 triage-agent

Triage Assessment

Classification: bug-confirmed

Summary

The atomic sandbox-policy update path persists a new revision and annotations but does not wake local WatchSandbox(follow_status=true) observers. This is a confirmed gateway policy-lifecycle defect, not user error.

The report's supervisor impact is overstated: sandbox supervisors poll GetSandboxConfig on a timer and do not consume SandboxWatchBus. The direct impact is stale CLI/SDK/TUI status streams. #2518 is the separate same-hash policy-acknowledgement defect.

Investigation

In current main (b1c7ff68), put_policy_revision_atomic commits successfully. No notification follows; the freshly written record then takes the same-hash early return, bypassing the later notification at line 2261.

The existing update_config_same_policy_hash_with_new_provenance_creates_revision test confirms the exact revision/provenance transition; the focused test passes on current main but does not assert watcher delivery. SandboxWatchBus documents that producers notify whenever persisted sandbox records change, and WatchSandbox blocks on that bus.

Searches found no duplicate or merged fix. Open PR #2257 adds eventual shared-store polling and would partially mask the symptom, but it does not restore this local post-commit notification invariant and is not a duplicate.

Recommendation

Notify once immediately after the atomic retry block commits successfully and before the fallible reload/same-hash return. Do not notify for same-policy/same-provenance no-ops, retry conflicts, or failed writes. Extend the regression test to subscribe before UpdateConfig, assert one received event, then assert Empty to enforce exactly-once behavior.

Recommended labels: area:gateway, area:policy. Remove state:triage-needed and assign issue type Bug. Do not apply state:agent-ready; that remains a human decision.