Repository navigation
fix(app): refetch the Home session index on window focus - #55301
shreyanshj10 wants to merge 2 commits into
Conversation
|
The following comment was made by an LLM, it may be inaccurate: |
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
The one-line fix does what it says. A periodic refetch of GET /api/session would show sessions created by another opencode serve on the same database: I ran the #55098 script from source, and the second server's stream got no session.created while its session list already included the session. I did not run the desktop or web app, so I didn't see the Home list refresh. bun test src/home/sessions (25 pass) and the packages/app typecheck are clean. Public API unchanged.
Main concern: each refetch reloads the whole session history, not one page. loadHomeSessionIndex keeps fetching 5,000 sessions at a time until it reaches the end. With this change, every client on Home does that every 30s, against local and remote servers alike, for a setup (two servers sharing one opencode.db) that maintainers may not consider supported. Refetching on focus/visibility would cover "I switched back and the list is stale" much more cheaply. Otherwise the server-side event fix (#45549) is the better place for this. The added code comment isn't needed for a one-option change and can be dropped.
| // A second server on the same database publishes `session.created` on its own process's bus, | ||
| // so nothing on this stream ever announces the sessions it creates. Re-read the index on the | ||
| // staleness window rather than waiting for a remount or a reconnect to be the only way back. | ||
| refetchInterval: 30_000, |
There was a problem hiding this comment.
Each refetch runs loadHomeSessionIndex, which fetches every page of the session history (5,000 per page until the end), not just the newest rows. With refetchInterval: 30_000 every client on Home repeats that every 30s, for every user and every server (including remote ones), to cover the two-servers-on-one-database case. Could this be refetchOnWindowFocus: true (and/or a refetch on visibilitychange) instead, or at least a much longer interval? That would cover returning to the app while costing far less.
The 30s interval had every client on Home walk the whole session history on a timer. Opt the query into focus refetching instead: returning to the window re-reads the index once it is past its stale time, and nothing runs while the window is away.
shreyanshj10
changed the title
|
Thanks, that's a fair objection and I've taken the focus route. You're right about the cost: The interval is gone. The query sets The four refetch options now sit in a small #53752 and this don't collide as far as I can see: that one invalidates the index when the stream This now covers "I came back and the list is stale" and nothing more; a session created on another |
Issue for this PR
Fixes #55098
Type of change
What does this PR do?
app.tsxturnsrefetchOnMount,refetchOnReconnectandrefetchOnWindowFocusoff for everyquery.
home-sessionsopts back into mount and reconnect but not focus, and["home-sessions", conn]is only ever invalidated by Home's own rename and delete paths. Sonothing refreshes the list except a remount or a reconnect.
That is enough while every session is announced on this client's own stream. It is not enough when
a second
opencode serveshares the database: the other process publishessession.createdon itsown bus, so the new session is in
GET /api/sessionon both servers while only one streamannounced it, and the client that missed the event needs a restart to see it.
So the query opts back into focus refetching too, and Home re-reads the index when you return to
the window.
staleTimestays at 30s and Query only refetches on focus once the data is past it, soswitching straight back costs nothing, nothing runs while the window is away, and the focus manager
owns the
visibilitychangelistener, so there is no listener to leak and no refetch stacking on onein flight. The four refetch options sit in
home/sessions/refetch.tsand are spread at the singlecall site.
Client half only, and only for "I came back and the list is stale": a session created elsewhere
while Home stays in front still waits for the next focus. A cross-process event bus (#45549) is
what would make the list update immediately.
How did you verify your code works?
Ran the new
home/sessions/refetch.test.tscase, the typecheck inpackages/app, and oxlint on thechanged files. The new case mounts a client with the app-wide defaults, lets the index go stale,
fires
visibilitychangeand expects exactly one refetch - and none while the data is still fresh.It fails without the
refetchOnWindowFocusopt-in.For a real second server, the repro script on the issue is the setup - two
opencode serveprocesses on one data dir, create a session on B, then come back to Home on A. The issue's own
finding is that the session shows up there only after a restart.
Screenshots / recordings
No visual change - the same rows, refreshed when you return to them.
Checklist
Added by the opencode bot (AI-generated).
Related: #45549, #53146, #51213