* fix(status): pick latest assistant message in single pass
Sync reconciliation can splice messages out of array order, so the
previous "filter + sort + last" pipeline could pick the wrong record
as the latest assistant message and surface a stale status.
Replace it with a single-pass scan that compares created-time (tiebreak
by id) — same selection, but resilient to non-sorted message arrays.
* refactor: use comparator + running max for latest assistant pick
Address Greptile review: collapse the dual-exit-point single-pass max
finder (separate continue + isNewer branches, repeated null checks)
into a single isLater(a, b) comparator with one running-max comparison
per iteration. Same selection rule, easier to verify.
---------
Co-authored-by: vhqtvn <8930337+vhqtvn@users.noreply.github.com>
* fix(sessions): align archive-cascade count with executed list
When archiving a parent session, the dialog showed the total descendant
count but the actual archive request skipped already-archived
descendants — so the toast/result didn't match what the user was told.
Collect descendants once, then filter per-action: hard-delete cascades
to every descendant; archive skips already-archived ones. Dialog count
and the ID list passed to archiveSessions/deleteSessions now agree.
* fix(sessions): snapshot descendant IDs at dialog open
Address Greptile review: handleDeleteSession populated the dialog
count from a fresh collectDescendants() call, then confirmDeleteSession
re-collected at confirm time — so a background sync that mutated
childrenMap while the dialog was open could re-introduce the same
count-vs-executed mismatch this PR fixed.
Store the computed descendant IDs in deleteSessionConfirm and pass
them through to executeDeleteSession, so the executed list is always
the snapshot the user was shown. The no-dialog direct-execute path
also routes through the snapshot for consistency.
---------
Co-authored-by: vhqtvn <8930337+vhqtvn@users.noreply.github.com>
The repo's .nvmrc contained the literal string `lts`, which isn't a
valid nvm version specifier — running `nvm use` (or any tool that
respects .nvmrc) fails with "Version 'lts' not found". When that
happens, the shell falls back to whatever Node is on PATH, which
often doesn't meet vite's >= 20.19 / 22.12 requirement and silently
breaks the build.
`lts/*` is the canonical "latest LTS" specifier in nvm and resolves
correctly. Same intent, working syntax.
Co-authored-by: vhqtvn <8930337+vhqtvn@users.noreply.github.com>
The archived bucket is the only sidebar group that routinely grows
into the hundreds or thousands of rows (projects accumulate archived
sessions over time). On main, expanding the bucket mounts every row
at once — for a project with ~1400 archived sessions that's
thousands of subscriptions, layouts, and event handlers committed
on a single render.
Wrap the archived bucket's row map in `@tanstack/react-virtual`
(already in deps) when the visible count crosses 50. DOM stays
bounded to the visible window + overscan regardless of total size.
Implementation notes:
- Threshold + estimate are local constants; only the archived
bucket is gated, every other group keeps its eager render.
- The virtualizer needs a scroll element. The sidebar's scroll
lives on an ancestor `ScrollableOverlay`; rather than threading
a ref through every intermediate component for this one use
case, we walk up the DOM from the row container.
- `measureElement` handles variable row heights (subagent
expansion, status indicators, etc.).
- ResizeObserver re-measures on sidebar resize, mirroring the
pattern in ChangesSection.
Co-authored-by: vhqtvn <8930337+vhqtvn@users.noreply.github.com>
The same session can appear in two render contexts at once — most
visibly under "Recent" and under its project's root group. Expansion
state was keyed by bare session id, so toggling the chevron in one
context flipped it in the other; the user clicked one row and a
duplicate elsewhere expanded/collapsed in sync.
Switch the expansion set to composite keys of the form
`<renderContext>:<active|archived>:<sessionId>`. SessionNodeItem
already computes this exact shape for its menu instance key
(menuInstanceKey); reuse it as expansionKey so the two render-time
instances of one session keep independent expand state. Updated:
- isExpanded reads `expandedParents.has(expansionKey)`.
- Chevron click / Enter / Space pass `expansionKey` to toggleParent
instead of session.id.
- The memo-equality check compares the same composite key on both
sides so it correctly re-renders when only one context's state
changes.
- toggleParent's parameter is renamed `expansionKey` to reflect the
new shape; the implementation is unchanged.
- The auto-expand-parent-on-subagent-navigation effect doesn't know
which context the user will look at the parent in, so it fans the
parentID out to all four (project|recent) × (active|archived)
combinations.
Storage is bumped to `oc.sessions.expandedParents.v2`. Existing v1
data (bare session ids) is one-shot migrated by fanning each id
across all four contexts and rewritten under the v2 key; the v1 key
is then removed so a downgrade-then-reupgrade doesn't re-migrate.
Co-authored-by: vhqtvn <8930337+vhqtvn@users.noreply.github.com>
* fix: preserve state when reconnect-time fetches fail
Several client API methods swallowed fetch/SDK errors and returned an
empty value (`[]`, `{}`), which was indistinguishable from a successful
"server says nothing here" response. Reconnect resync paths trusted that
empty result as authoritative and deleted local state — so after a
network blip (sleep/wake, wifi reconnect, tunnel switch), the UI could
show:
- sessions stuck on the "running" indicator (status never cleared)
- pending permission prompts disappearing from the UI
- pending question prompts disappearing from the UI
and only a page reload would recover. A related case: `listAgents`
silently returning `[]` defeated the 3-attempt retry loop in
`useAgentsStore` because the loop never saw an error.
The systematic fix:
- `getSessionStatusForDirectory` now returns `null` on fetch failure
(vs the previous `{}`); the reconnect resync treats only a non-null
response as authoritative — candidates missing from the response are
written as `{type: "idle"}`, candidates after a failure are left
untouched.
- `listPendingPermissions`, `listPendingQuestions`, and `listAgents`
now throw on SDK/network failure. The pre-existing outer try/catch
blocks in `resyncBlockingRequestsForDirectory` and the retry loop in
`useAgentsStore` were already in the right shape — they just never
fired because no exception was thrown. A small `formatSdkError`
helper renders the SDK `{data, error}` shape into the thrown message.
- `permissionStore.setSessionAutoAccept` catches the new throw and
falls back to whatever sync-store snapshots provide; the next SSE
event or reconnect resync will catch up anything missed.
AGENTS.md gets a new "Distinguish fetch failure from empty success"
subsection documenting the principle (throw vs `T | null` patterns,
when to pick which, the retry-loop trap) so this doesn't regress.
Adds 3 regression tests covering the resync paths: existing
questions/permissions are preserved when the corresponding `list*`
method throws, and a permission-fetch failure does not block the
question block from running (verifies per-block try/catch isolation).
* fix: pause reconnect loop when offline or hidden
The SSE/WebSocket reconnect loop retried indefinitely with no awareness
of whether the browser was online or whether the tab was even visible.
Three issues compounded:
- No `online`/`offline` event handling. With a foreground tab on a dead
network, we'd hit the server every ~5s forever, and on network
recovery we'd wait up to ~5s for the next probe instead of reacting
to the `online` event.
- No visibility awareness. A backgrounded PWA on a flaky link kept
probing at the same rate as a foreground tab. The browser does
throttle hidden-tab timers, but the intent wasn't expressed in code.
- The "exponential backoff" math
`min(5000, max(retryDelayMs, 250) * (failures <= 1 ? 1 : 2))`
re-initialized `retryDelayMs` to 250 every iteration, so the cap of
5s was never reached — we waited 500ms forever after the second
failure. Not actually exponential.
Now:
- `online` event aborts the current attempt (if disconnected) and
cuts inter-attempt waits short. `offline` event aborts so the loop
enters the slow-probe path immediately.
- `computeRetryDelay` returns the long cap (60s) when `navigator.onLine`
is false or the tab is hidden; the short cap (5s) when foreground +
online. The `online` event is the expected recovery path; the 60s cap
is a fallback for browsers that miss the event.
- Real exponential growth: `BASE * 2^min(failures-1, 8)`, clamped.
- New `waitForRetry` helper interrupts on `online`,
visibility-becomes-visible, and abort signal — so visibility/network
recovery doesn't wait out the rest of the current sleep.
AGENTS.md gets a "Reconnect-loop pacing" subsection alongside the
fetch-failure rule, since they're the same family of resilience
concerns.
One regression test: simulates offline + failed first attempt + `online`
event after the failure; verifies the next attempt fires within seconds
instead of waiting the full 60s offline cap.
* fix: long-cap backoff for permanent 4xx server errors
Before this commit the reconnect loop didn't distinguish HTTP error
types. A stuck-path client (wrong URL after server upgrade) or an
expired-auth client (stale token) would hit the server at the normal
5-second cap forever — ~12 reqs/min, indefinitely, with no path to
recovery besides the user reloading.
Now the catch block extracts an HTTP status (looking on `error.status`
and `error.response.status` — the SDK exposes both depending on the
code path) and overrides the backoff:
- 4xx other than 408/429 → use the long cap (60s) immediately.
Blind retries won't fix wrong path / bad auth / forbidden, so don't
pound the server. waitForRetry's `online` / visibility-visible
interrupters still apply — when an operator fixes the server-side
config and the client comes back to foreground, recovery is prompt.
- 408 (Request Timeout) and 429 (Too Many Requests) → normal
exponential path. Those are retryable in spirit.
- 5xx / network / unknown → normal exponential path. Unchanged.
AGENTS.md gets a new bullet under "Reconnect-loop pacing" covering
this — the rule fits naturally alongside the existing `navigator.onLine`
and visibility signals.
Two regression tests:
- A 404-throwing SDK doesn't fire a second attempt within 250ms (proves
we left the exponential path). After `online` interrupts the wait,
subsequent attempts fire promptly — proves the override doesn't break
recovery once the underlying problem is fixed.
- A 429-throwing SDK recovers within 2s — proves 429 still hits the
fast exponential path and isn't caught by the permanent-error branch.
---------
Co-authored-by: vhqtvn <8930337+vhqtvn@users.noreply.github.com>
* fix(web): support service worker notifications in PWAs
* fix(web): skip service worker wait without registration
---------
Co-authored-by: vhqtvn <8930337+vhqtvn@users.noreply.github.com>
