Repository navigation
Paginated mode swallows list-fetch failures: #1954's error UI never fires, and the connect-time load can leave an unhandled rejection #1998
Description
Activity
Triage: Priority Medium (total 6)
- Severity 3 — a real feature is broken under a documented setting; the workaround (turn pagination off) is partial
- Urgency 2 — wanted eventually; nothing is blocked on it
- Bonuses: +1
buglabel
Board: #28, Status
Todo, milestone v2.3.0.I traced the paginated-list failure path: with
paginatedListsenabled, a rejectedtools/list,prompts/list, orresources/listpage is not attached to the active paged state. The sidebar can therefore appear empty, while the connect-timevoid loadPage(...)call can leave an unhandled rejection. I can implement a small shared paged error-state/retry path, preserve the managed aggregate path for non-paginated mode, and add regression coverage for first-page and subsequent-page failures, retry-success error clearing, and connect-time rejection handling. I understand that this repository asks external contributors to provide an implementation prompt rather than open a PR directly. Would a maintainer be willing to invite me or grant the appropriate contribution access, or have a maintainer open a PR from an external branch? If not, I am happy to leave only a detailed implementation prompt and test plan here.- linked a pull request that will close this issuefix: surface list-fetch failures in paginated mode (#1998) #2047
on Aug 18, 2026 - added a commit that references this issue
on Aug 18, 2026
Found by Copilot reviewing the v2.2.0 milestone merge (#1993), verified against the code.
#1954 made a failed
tools/list/prompts/list/resources/listsurface an alert with a Retry instead of an empty panel — but it wired the error off the aggregate managed stores only. With thepaginatedListssetting on (#1721), those stores are not the display source, so the fix does not apply:ManagedListStatedeliberately skips its connect-time andlist_changedaggregate walk in paginated mode (deferWhenPaginated,core/mcp/state/managedListState.ts:158-166,241-249), sotoolsLoadError/promptsLoadError/resourcesLoadErrorstaynull.PagedToolsState/PagedPromptsState/PagedResourcesState— which do drive the sidebar in that mode — have no error state at all.loadPage()has atry { … } finally { this.loading = false }with no catch (core/mcp/state/pagedToolsState.ts:98-124and siblings), so a rejection propagates to the caller.void this.loadPage(undefined)(pagedToolsState.ts:58,pagedPromptsState.ts:46,pagedResourcesState.ts:47), so that rejection is floated — an unhandled rejection, which Enable @typescript-eslint/no-floating-promises so an unhandled rejection can't fail the gate again #1959 is separately trying to make fatal.Net effect: with pagination on, a failing list still shows an empty sidebar with no alert and no Retry — the exact behavior #1954 set out to remove.
Expected
A failed page load in paginated mode surfaces the same alert + Retry as the aggregate path.
Suggested shape
errorChangeevent or an error field on the pagination payload), setting it in acatchinloadPageand clearing it on the next success.App.tsxselect the error from whichever source is active for the currentpaginatedListssetting, rather than always reading the managed stores (clients/web/src/App.tsx:4387).void loadPage(...)calls should route into the same error state.Repro
test-servers/configs/pagination-http.jsonwith Fetch Lists One Page at a Time on, against a server whosetools/listrejects.