Add manual refresh button for marketplace to prevent automatic API calls

[indiesewell]

App Version

v3.21.3

API Provider

Anthropic

Model Used

Claude 4 Sonnet

🔁 Steps to Reproduce

Description

Currently, the marketplace automatically fetches data from remote APIs, which can cause issues for users behind VPNs or firewalls (especially those blocked by Cloudflare). This results in:

1. Infinite API retry loops for VPN users
2. Unnecessary network requests when MCP features are disabled
3. Poor user experience with constant loading states

Proposed Solution

Replace automatic API fetching with a manual refresh button in the marketplace UI.

Current Behavior

• Marketplace automatically fetches remote data on load
• 5-minute cache with automatic retry when expired
• No user control over when API calls are made

Proposed Behavior

• Show local installed items by default (no API calls)
• Add a prominent "🔄 Refresh Marketplace" button
• Only fetch remote data when user explicitly clicks refresh
• Maintain 5-minute cache for successful requests

Benefits

1. Better UX for VPN users - No more infinite loading/retry loops
2. Reduced network usage - API calls only when needed
3. Faster initial load - Show local items immediately
4. User control - Users decide when to fetch remote data
5. Respects MCP settings - No API calls when MCP is disabled

Implementation Suggestions

UI Changes

// Add refresh button to MarketplaceView header
<div className="flex gap-2 items-center">
  <Button onClick={handleRefreshMarketplace}>
    🔄 {t("marketplace:refresh")}
  </Button>
  <Button onClick={onDone}>
    {t("marketplace:done")}
  </Button>
</div>

Backend Changes

// Modify getCurrentItems to prioritize local items
async getCurrentItems(): Promise<MarketplaceItem[]> {
  // Return local installed items by default
  return this.getLocalInstalledItems()
}

// Keep existing getMarketplaceItems for manual refresh
async getMarketplaceItems(): Promise<{items: MarketplaceItem[]}> {
  // Existing remote API logic
}

User Stories

As a VPN user, I want to avoid automatic API calls that get blocked by Cloudflare, so I can use the marketplace without infinite loading states.

As a developer, I want to see my locally installed modes/MCPs immediately, without waiting for remote API calls.

As a user with MCP disabled, I don't want the extension making unnecessary API calls to marketplace endpoints.

Alternative Solutions Considered

1. Better error handling - Still results in failed API calls
2. Longer cache duration - Delays the problem but doesn't solve it
3. Request deduplication - Reduces calls but doesn't eliminate them

Related Issues

This addresses the core issue where marketplace API calls:

• Block UI for VPN users
• Consume bandwidth unnecessarily
• Ignore MCP disabled state
• Provide poor offline experience

Priority

Medium-High - Affects user experience for VPN users and those with limited connectivity.

---

💥 Outcome Summary

Environment:

• VSCode Extension: Roo Code
• Affected Users: VPN users, users with MCP disabled, users with limited connectivity
• Current Workaround: Disable MCP entirely to avoid API calls

📄 Relevant Logs or Errors (Optional)

[daniel-lxs]

Thank you for your proposal. While a manual reload button might help as a fallback, I believe the issues you're encountering can be addressed more effectively through the following improvements:

1. Suggested update in issue #4996
2. Avoid making API requests when the marketplace is disabled.
3. Reduce the number of API calls, which should already be improved with fix: resolve marketplace timeout issues and display installed MCPs (#4817) #4941.

These changes will allow users to receive seamless Marketplace updates without needing to manually refresh.

The root issue is that RemoteConfigLoader.fetchWithRetry() treats all errors as retryable using exponential backoff. However, Cloudflare challenges often return HTML or 403 status codes that cannot be resolved through programmatic retries, leading to infinite loops, particularly for users behind VPNs.

Adding error classification to distinguish between retryable and non-retryable responses, along with honoring the marketplace settings, should resolve the underlying issue while preserving automatic functionality for users without network restrictions.

I'll close this proposal for now but I'm curious to hear your thoughts about this.