Summary
On a fleet client, the panel's Sessions dropdown remained empty across multiple
window reloads even though the hub held all sessions, the session-list APIs
returned them when queried directly, and the same app displayed them in a
regular browser. The hub's request log showed the webview made no session-list
requests at all: it served a persisted empty snapshot from client-side storage
instead of re-fetching on boot.
Context
- Desktop app panel (webview iframe) on a fleet client; hub on Linux x64.
- Engine: hub binary was a pre-
v1.18.10-amicode.21 build at first observation,
then upgraded to v1.18.10-amicode.22 — the empty dropdown persisted across
both, isolating the fault to client-side persisted state, not the hub.
- Extension vendored-engine pin in the affected install:
v1.17.3-amicode.4.
- Server-side data was verified healthy throughout (direct API queries returned
hundreds of sessions).
Expected vs actual
- Expected: reopening or reloading the panel rebuilds session lists from the
server; persisted client state is invalidated/refetched on boot (or at least
clearable from inside the product).
- Actual: the webview served an empty cached session list indefinitely; the
request log contained zero session-list requests across all reloads. Recovery
required manually deleting the client's webview cache/storage folders.
Reproduction sketch
- Get the client into a state where a session list fetched empty (e.g. server
downtime or a scoping mismatch at first boot).
- Fix the server side.
- Reload the window / reopen the panel — the dropdown still shows nothing; no
session-list request is issued.
Diagnostics
- No run active (fleet-ops session, not a solve).
- Evidence: hub front-door request log showing zero session-list fetches across
reloads, while direct API queries succeeded.
- Same app rendered the full session list in a plain browser tab (fresh storage).
- no absolute paths, no binary uploads
intake: not-ready — mature per the maturity contract before picking up
suggested_path: B
diagnostics: inline
upstream: none found
Summary
On a fleet client, the panel's Sessions dropdown remained empty across multiple
window reloads even though the hub held all sessions, the session-list APIs
returned them when queried directly, and the same app displayed them in a
regular browser. The hub's request log showed the webview made no session-list
requests at all: it served a persisted empty snapshot from client-side storage
instead of re-fetching on boot.
Context
v1.18.10-amicode.21build at first observation,then upgraded to
v1.18.10-amicode.22— the empty dropdown persisted acrossboth, isolating the fault to client-side persisted state, not the hub.
v1.17.3-amicode.4.hundreds of sessions).
Expected vs actual
server; persisted client state is invalidated/refetched on boot (or at least
clearable from inside the product).
request log contained zero session-list requests across all reloads. Recovery
required manually deleting the client's webview cache/storage folders.
Reproduction sketch
downtime or a scoping mismatch at first boot).
session-list request is issued.
Diagnostics
reloads, while direct API queries succeeded.
intake: not-ready — mature per the maturity contract before picking up
suggested_path: B
diagnostics: inline
upstream: none found