[Bug] MCP Marketplace causes infinite request loops and high CPU usage

[indiesewell]

App Version

v3.20.1

API Provider

Anthropic

Model Used

Claude 4 Sonnet

🔁 Steps to Reproduce

🐛 Bug Report

Affected Version: v3.20.1 and later

1. Summary

Since the introduction of the MCP Marketplace, the extension can enter an infinite loop of API requests, causing high CPU usage and making the extension completely unresponsive. This is triggered by two main factors:

1. Inefficient Data Fetching: The marketplace data is fetched on every single UI state update, regardless of whether the user is interacting with the marketplace.
2. Network Request Failures: In certain network environments (especially behind a VPN or on slow connections), the API requests to fetch marketplace data fail or time out. This is likely due to a deeper issue with axios being blocked by Cloudflare's WAF (this will be detailed in a separate, related issue).

The combination of constant, unnecessary requests and frequent network failures creates a vicious cycle that paralyzes the extension.

2. Root Cause Analysis

A. Unconditional API Invocation

The primary performance issue lies in src/core/webview/ClineProvider.ts. The getStateToPostToWebview method unconditionally calls this.marketplaceManager.getCurrentItems(). Since this state-syncing method is called very frequently, it results in a flood of API requests, creating a huge performance bottleneck and exacerbating the network failure issue.

B. Network Request Instability

The requests made from src/services/marketplace/RemoteConfigLoader.ts are unreliable in some environments. While the root cause seems to be axios's incompatibility with Cloudflare, an immediate workaround is to switch to a more robust request mechanism like Node.js's native https module, which has proven to be more reliable in similar situations within this codebase.

3. Proposed Solution

This solution focuses on immediate mitigation of the performance and unresponsiveness bug.

1. Implement On-Demand Data Loading in ClineProvider.ts:

   • Wrap the marketplace data fetching logic in a conditional check. The data should only be fetched if the MCP feature is actually enabled by the user.

   Example Implementation:

   // In src/core/webview/ClineProvider.ts, inside getStateToPostToWebview()
   
   let marketplaceItems: any[] = [];
   let marketplaceInstalledMetadata: any = { project: {}, global: {} };
   
   const { mcpEnabled } = await this.getState();
   if (mcpEnabled) {
       marketplaceItems = (await this.marketplaceManager.getCurrentItems()) || [];
       marketplaceInstalledMetadata = await this.marketplaceManager.getInstallationMetadata();
   }

2. Stabilize Network Request in RemoteConfigLoader.ts:

   • As a quick and effective fix, replace the axios.get() call with a request using the native https module. This has been shown to bypass WAF issues.
   • Note: This is a tactical fix. A broader, strategic discussion about replacing axios throughout the application will be raised in a separate issue.

   Example Implementation:

   // In src/services/marketplace/RemoteConfigLoader.ts
   import * as https from 'https';
   
   private async fetchWithRetry<T>(url: string, maxRetries = 3): Promise<T> {
       // ... (retry logic)
       try {
           return new Promise<T>((resolve, reject) => {
               const options = {
                   // ... (hostname, path, etc. from URL)
                   method: "GET",
                   timeout: 60000,
                   headers: {
                       "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36",
                   },
               };
               const req = https.request(options, (res) => {
                   let data = "";
                   res.on("data", (chunk) => (data += chunk));
                   res.on("end", () => {
                       if (res.statusCode && res.statusCode >= 200 && res.statusCode < 300) {
                           resolve(data as T); // Return raw string for YAML parsing
                       } else {
                           reject(new Error(`Request failed: ${res.statusCode}`));
                       }
                   });
               });
               req.on("error", (e) => reject(e));
               req.end();
           });
       } catch (error) {
           // ... (error handling)
       }
       // ...
   }

4. Impact

• Severity: Critical. This bug makes the extension unusable for a growing number of users.
• Urgency: High. Fixing this is essential to restore core functionality.

Implementing these two changes will immediately resolve the infinite loop and make the extension stable again for affected users.

[indiesewell]

Title: Blocking Marketplace API Requests on Every Conversation Breaks Core Plugin Functionality (v3.21.0)

Description
Since version v3.21.0, the plugin attempts to fetch two Roo Marketplace API endpoints:

https://app.roocode.com/api/marketplace/mcps

https://app.roocode.com/api/marketplace/modes

These requests are made not only during initial startup, but also on every new conversation or task creation. In environments with slower or high-latency connections, this behavior causes:

Severe delays in loading the plugin UI;

The “New Task” window failing to open or taking 10–30 seconds+;

Repeated blank panels or freezing during task creation;

Completely unrelated features being blocked by Marketplace loading;

These two API calls, while accessible in a browser, seem to be:

Blocking (synchronous) calls that stall the entire plugin interface;

Retried on every key operation, not cached or decoupled;

Not critical to core features like task execution, yet treated as required.

Steps to Reproduce

Open roocode on a slower network.

Try to start a new task or conversation.

Observe that the plugin is frozen or unresponsive until the Marketplace API responds.

Expected Behavior

Marketplace APIs should load asynchronously, and never block primary actions like starting a task.

API results should be cached locally to avoid repeated calls.

If the Marketplace is unreachable, the plugin should still function fully.

Impact

Plugin becomes unusable in slower or unstable networks.

Tasks and workflows cannot be started reliably.

Users are blocked from using core features that should not depend on Marketplace availability.

Suggested Fixes

Decouple Marketplace fetches from core plugin operations.

Load Marketplace data lazily, only when the Marketplace panel is actively opened.

Add caching, timeout handling, and fallback UI behavior.

Make sure new conversations/tasks never wait for external marketplace calls.

Severity: High — blocks primary user workflows under common real-world network conditions.

Thank you for your attention to this urgent issue.

[indiesewell]

Update – Critical Behavior Identified
After further testing, we’ve discovered that these Roo Marketplace API requests are triggered on every new task or conversation, not just during initial load.

This causes major functionality issues:

New tasks fail to open entirely if the Marketplace API is slow or unreachable.

The plugin UI freezes repeatedly during normal use.

Marketplace data is re-fetched unnecessarily on every interaction, even when not viewing the Marketplace.

This transforms a UI delay into a full workflow blocker.

Please treat this as a critical issue — core features like conversation and task creation should never depend on Marketplace availability.

Suggested urgent patch:

Disable Marketplace API calls during non-Marketplace actions (e.g., task start).

Implement caching and lazy-loading.

Add timeout and fallback to ensure plugin remains usable regardless of Marketplace response.

Thank you again for your help and rapid attention.

[daniel-lxs]

Thank you @indiesewell for reporting this issue.

This seems to be related to #4817.

I agree, the marketplace shouldn't request the items on every new task, this is due to the way the state updates are handled.

[indiesewell]

Thank you @indiesewell for reporting this issue.

This seems to be related to #4817.

I agree, the marketplace shouldn't request the items on every new task, this is due to the way the state updates are handled.

Hi, Since I used a VPN, I could see that not only every new task, but every chat would request the mcp api.

The code above temporarily solved the problem. You can turn off the mcp service, but if you turn on the mcp service, even if you don't install any MCP, you will still request the api every time. I look forward to your fix, I didn't continue to study it further.