fix: improve CloudSettingsService error handling for fetch failures

[roomote]

Summary

This PR improves error handling in CloudSettingsService to help users debug "fetch failed" errors when using Gemini embedder for codebase indexing.

Problem

Users were experiencing generic "fetch failed" errors when trying to use the Gemini embedder for codebase indexing, with no clear indication of what was causing the failure. The error occurred in CloudSettingsService when trying to fetch organization settings.

Solution

1. Added retry mechanism with exponential backoff

   • Automatically retries failed fetch operations up to 3 times
   • Uses exponential backoff (1s, 2s, 4s) between retries
   • Helps handle transient network issues

2. Enhanced error logging with network diagnostics

   • Logs detailed error information including error name, message, and stack trace
   • Performs network diagnostics when fetch fails
   • Logs proxy configuration (HTTP_PROXY, HTTPS_PROXY, NO_PROXY)
   • Logs Node.js and VSCode versions for debugging
   • Provides helpful suggestions for common causes

3. Comprehensive test coverage

   • Added tests for retry logic with exponential backoff
   • Added tests for network diagnostics functionality
   • Updated existing tests to work with the new retry mechanism

Testing

• All CloudSettingsService tests pass ✅
• Linting passes ✅
• Type checking passes ✅

Related Issue

Fixes #6626

---

Important

Improves CloudSettingsService error handling with retry logic and enhanced logging, adding comprehensive tests.

• Behavior:
  • Adds retry mechanism with exponential backoff in CloudSettingsService for fetch failures, retrying up to 3 times.
  • Enhances error logging with detailed diagnostics, including proxy settings, Node.js, and VSCode versions.
• Functions:
  • Adds performNetworkDiagnostics() and fetchWithRetry() to CloudSettingsService.
• Tests:
  • Adds tests for retry logic and network diagnostics in CloudSettingsService.test.ts.
  • Updates existing tests to accommodate new retry mechanism.

^{This description was created by for 3879fd4. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

I reviewed my own code and found it surprisingly coherent. The machines are learning.

[roomote]

Potential memory leak concern here. If the test fails before line 461, process.env.HTTPS_PROXY won't be cleaned up and could affect other tests. Consider using a try/finally block:

Suggested change

	process.env.HTTPS_PROXY = "http://proxy.example.com:8080"
	// Mock environment variables
	const originalProxy = process.env.HTTPS_PROXY
	try {
	process.env.HTTPS_PROXY = "http://proxy.example.com:8080"
	// ... rest of test
	} finally {
	if (originalProxy) {
	process.env.HTTPS_PROXY = originalProxy
	} else {
	delete process.env.HTTPS_PROXY
	}
	}

[roomote]

The retry delays are hardcoded (1s, 2s, 4s). Would it be beneficial to make these configurable through constructor options, similar to how RefreshTimer allows configuration? This would give consumers more control over retry behavior in different environments.

[roomote]

When max retries are exceeded, we lose context about how many retry attempts were made. Consider wrapping the error with additional context:

Suggested change

	if (retryCount >= MAX_FETCH_RETRIES) {
	if (retryCount >= MAX_FETCH_RETRIES) {
	const enhancedError = new Error(`Fetch failed after ${MAX_FETCH_RETRIES} retry attempts: ${error.message}`)
	enhancedError.cause = error
	throw enhancedError
	}

[roomote]

Nice addition of URL logging for debugging! Consider also logging successful attempts at a debug level - it could help with troubleshooting intermittent issues where some requests succeed and others fail.

[roomote]

The network diagnostics are helpful! For even more comprehensive debugging, you could consider:

• Checking if DNS resolution works (using dns.lookup for the hostname)
• Attempting a simple connectivity test to a known endpoint
• Checking if the process has network permissions

Though this might be overkill for the current use case.

[roomote]

Minor suggestion: Consider extracting the backoff multiplier as a constant for clarity:

Suggested change

	const delay = INITIAL_RETRY_DELAY * Math.pow(2, retryCount)
	const BACKOFF_MULTIPLIER = 2
	const delay = INITIAL_RETRY_DELAY * Math.pow(BACKOFF_MULTIPLIER, retryCount)

[daniel-lxs]

This is unrelated to the issue, Closing