Skip to content

Conversation

@daniel-lxs
Copy link
Member

@daniel-lxs daniel-lxs commented Oct 29, 2025

Problem

Part of the webview memory mitigation effort. The backend was always fetching and returning all router models from all providers, even when the frontend only needed models from a specific provider. This resulted in unnecessarily large payloads being cached and reconciled in the webview.

Solution

Add support for provider filtering in the requestRouterModels handler. The frontend can now send a providers filter via message.values.providers, and the backend will only fetch and return models for those specific providers.

Changes

  • webviewMessageHandler: Honor message.values.providers filter
    • When filter is present and non-empty, only fetch requested providers
    • Maintain backward compatibility - fetch all providers when no filter provided
  • Test: Comprehensive test coverage for provider filtering logic

Impact

Before: Backend always returned all router models (openrouter, roo, litellm, etc.) regardless of which provider was needed

After: Backend can return filtered subset (e.g., only Roo models when providers: ["roo"] is requested)

Payload size reduction: Instead of 8+ provider catalogs, can return just 1

Files Changed

  • src/core/webview/webviewMessageHandler.ts
  • src/core/webview/__tests__/webviewMessageHandler.routerModels.spec.ts (new)

Testing

  • ✅ Test verifies provider filtering returns only requested providers
  • ✅ Test verifies backward compatibility with no filter
  • ✅ All backend tests passing

Part of

This is the second PR in a series to reduce webview memory usage:

  1. ✅ PR fix: Gate auth-driven Roo model refresh to active provider only #8915 - Gate auth-driven Roo model refresh
  2. This PR - Backend provider filtering
  3. Next: Frontend provider-scoped fetches

Dependencies

This PR is independent and can be merged before or after #8915. However, it enables the frontend filtering in PR #3 to work effectively.


Important

Adds provider filtering to webviewMessageHandler for requestRouterModels, reducing payload size by fetching only specified providers.

  • Behavior:
    • webviewMessageHandler now supports provider filtering for requestRouterModels using message.values.providers.
    • Fetches models only for specified providers; defaults to all if no filter is provided.
  • Testing:
    • New test file webviewMessageHandler.routerModels.spec.ts added.
    • Tests for provider filtering and backward compatibility.
  • Impact:
    • Reduces payload size by fetching only necessary provider models.
    • Maintains backward compatibility by fetching all models if no filter is specified.

This description was created by Ellipsis for 0354924. You can customize this summary. It will automatically update as commits are pushed.

Allows frontend to request specific subset of router models instead
of fetching all providers. This significantly reduces payload sizes
and memory usage when only specific providers are needed.

- Honor message.values.providers filter in requestRouterModels handler
- Fetch only requested providers when filter is present
- Maintain backward compatibility with existing aggregate behavior
- Add comprehensive test coverage for filtering logic
@daniel-lxs daniel-lxs requested review from cte, jr and mrubens as code owners October 29, 2025 20:19
@dosubot dosubot bot added size:L This PR changes 100-499 lines, ignoring generated files. enhancement New feature or request labels Oct 29, 2025
@roomote
Copy link

roomote bot commented Oct 29, 2025

Review Complete ✅

No issues found. The implementation is clean, type-safe, and well-tested.

What Was Verified

Type Safety: Filter parsing uses proper type guards and error handling to safely convert strings to RouterName types

Backward Compatibility: When no filter is provided, all providers are fetched (maintains existing behavior)

Edge Cases: Handles null/undefined, empty arrays, invalid provider names gracefully

Test Coverage: Comprehensive tests verify filtered, unfiltered, and single-provider scenarios

Error Handling: Failed provider fetches are caught via Promise.allSettled and reported individually

Code Quality: Follows existing patterns and coding standards


Follow Along on Roo Code Cloud

daniel-lxs added a commit that referenced this pull request Oct 29, 2025
Implements intelligent provider filtering in the frontend to request
only the models needed for the currently selected provider. This
dramatically reduces memory usage by avoiding unnecessary fetches
and smaller cache footprints.

- Add DYNAMIC_ROUTER_PROVIDERS set to identify providers needing models
- Disable useRouterModels for static providers (anthropic, openai-native, etc.)
- Pass provider-specific filters for dynamic providers
- Add observability logging to track request/response patterns
- Update tests for new behavior

Works with backend filtering (PR #8916) to achieve end-to-end
payload reduction.
@hannesrudolph hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Oct 29, 2025
@daniel-lxs daniel-lxs moved this from Triage to PR [Needs Prelim Review] in Roo Code Roadmap Oct 29, 2025
@hannesrudolph hannesrudolph added PR - Needs Preliminary Review and removed Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. labels Oct 29, 2025
daniel-lxs added a commit that referenced this pull request Oct 30, 2025
…er filter to avoid race with active-only payload (pairs with #8916 backend filtering)
@daniel-lxs daniel-lxs moved this from PR [Needs Prelim Review] to PR [Needs Review] in Roo Code Roadmap Oct 31, 2025
roo: {},
}
// Optional providers filter coming from the webview
const providersFilterRaw = Array.isArray(message?.values?.providers) ? message.values.providers : undefined
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for this filter to be an array instead of a single provider?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, if we only want to fetch one at a time I think we should make a function that only fetches one and use that instead of having the conditional logic. The only reason for backwards compatibility is that we broke this into multiple PRs, right? That seems ok but I think we should make a new method for the single lookup and then delete the old one once the webview is updated. Or just do it all in one PR, idk

daniel-lxs added a commit that referenced this pull request Oct 31, 2025
- Simplify backend to use single provider filter instead of array
- Use existing isDynamicProvider from @roo-code/types instead of duplicating
- Update frontend to request only the needed provider
- Gate router model fetches entirely for static providers
- Remove unnecessary debug logging
- Update tests to reflect new behavior

This combines and improves upon PRs #8916 and #8917 by:
1. Using a simpler single-provider API (provider: string instead of providers: string[])
2. Leveraging existing type definitions from packages/types
3. Eliminating race conditions through simpler request/response matching
4. Reducing payload sizes and network usage

Closes #8916
Closes #8917
@daniel-lxs
Copy link
Member Author

Closing in favor of combined PR #8956 which addresses all feedback and uses a simpler single-provider API

@daniel-lxs daniel-lxs closed this Oct 31, 2025
@github-project-automation github-project-automation bot moved this from New to Done in Roo Code Roadmap Oct 31, 2025
@github-project-automation github-project-automation bot moved this from PR [Needs Review] to Done in Roo Code Roadmap Oct 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request PR - Needs Review size:L This PR changes 100-499 lines, ignoring generated files.

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants