You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
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
Found by Copilot reviewing the v2.2.0 milestone merge (#1993), verified against the code.
#1954 made a failed tools/list / prompts/list / resources/list surface an alert with a Retry instead of an empty panel — but it wired the error off the aggregate managed stores only. With the paginatedLists setting on (#1721), those stores are not the display source, so the fix does not apply:
ManagedListState deliberately skips its connect-time and list_changed aggregate walk in paginated mode (deferWhenPaginated, core/mcp/state/managedListState.ts:158-166,241-249), so toolsLoadError / promptsLoadError / resourcesLoadError stay null.
PagedToolsState / PagedPromptsState / PagedResourcesState — which do drive the sidebar in that mode — have no error state at all. loadPage() has a try { … } finally { this.loading = false } with no catch (core/mcp/state/pagedToolsState.ts:98-124 and siblings), so a rejection propagates to the caller.
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
Give the paged states observable error state (an errorChange event or an error field on the pagination payload), setting it in a catch in loadPage and clearing it on the next success.
Have App.tsx select the error from whichever source is active for the current paginatedLists setting, rather than always reading the managed stores (clients/web/src/App.tsx:4387).
Stop floating the connect-time rejection — the void loadPage(...) calls should route into the same error state.
Repro
test-servers/configs/pagination-http.json with Fetch Lists One Page at a Time on, against a server whose tools/list rejects.
I traced the paginated-list failure path: with paginatedLists enabled, a rejected tools/list, prompts/list, or resources/list page is not attached to the active paged state. The sidebar can therefore appear empty, while the connect-time void 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.
Activity
cliffhall commentedon Aug 12, 2026
Triage: Priority Medium (total 6)
buglabelBoard: #28, Status
Todo, milestone v2.3.0.KirschBluteX commentedon Aug 14, 2026
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.Merge pull request #2047 from modelcontextprotocol/v2/fix/1998-pagina…
fix: surface list-fetch failures in paginated mode (modelcontextproto…