The dashboard's FastAPI server and a terminal CLI are separate processes sharing one SQLite session DB; there is no inter-process push channel. The Sessions page polled the 50 newest sessions every 5s for the "overview" card but only re-fetched the paginated sessions list on page change or delete, so a session started in a terminal never appeared in the list until the user navigated. Reuse the existing 5s overview poll as a change signal: when the head session id changes, silently reload the current page (no loading spinner flicker, no scroll/reset of expanded rows or bulk selection, which are keyed by id). The detection logic is extracted into a pure shouldRefreshSessions() helper with unit tests. Adds a minimal vitest setup for web/ (test script + config).
26 lines
1,001 B
TypeScript
26 lines
1,001 B
TypeScript
/**
|
|
* Decide whether the paginated sessions list should be silently
|
|
* re-fetched after an overview poll.
|
|
*
|
|
* The dashboard's FastAPI server and a terminal CLI are separate
|
|
* processes that share the same SQLite session DB. There is no
|
|
* inter-process push channel, so the Sessions page polls the 50 newest
|
|
* sessions every few seconds (the "overview" poll). When that poll
|
|
* surfaces a session id at the head of the list that we have not seen
|
|
* before, a new session was created in another process and the
|
|
* paginated list is stale — refresh it.
|
|
*
|
|
* Returns false on the very first poll (no baseline yet) and when
|
|
* either id is null (empty DB / transient empty response), so we never
|
|
* trigger a spurious reload on mount or while the DB is empty.
|
|
*/
|
|
export function shouldRefreshSessions(
|
|
prevNewestId: string | null,
|
|
currentNewestId: string | null,
|
|
): boolean {
|
|
return (
|
|
prevNewestId !== null &&
|
|
currentNewestId !== null &&
|
|
prevNewestId !== currentNewestId
|
|
);
|
|
}
|