Fixing /sse support (#12)

* /sse still not working

* Add transport type selector to inspector UI and comprehensive transport testing

- Add transport type dropdown to inspector UI (auto, HTTP, SSE) with session storage persistence
- Update test framework to support transport type selection in test scenarios
- Add comprehensive test cases covering:
  * Working /mcp endpoints with auto and HTTP transports
  * SSE endpoint with SSE transport (expected to pass)
  * SSE endpoint with auto transport (expected to fail - demonstrates current fallback issue)
- Test structure now provides clear visibility into transport-specific behavior
- All tests properly named and categorized for easy identification of failing scenarios

* Gearing up to "make amp do it"

* fix: improve SSE fallback logic in auto transport mode

- Fix issue where SSE fallback was not attempted when HTTP transport failed
- Specific error types (404, 405, CORS) now correctly trigger SSE fallback
- Allow SSE fallback even when component state is 'failed' from previous attempts
- Maintain proper error handling for non-fallback HTTP errors
- All 6 transport scenarios now pass integration tests

The core issue was that failConnection() was being called for HTTP errors
before returning 'fallback', which set the component state to 'failed' and
prevented the orchestration logic from attempting SSE fallback. Now only
specific HTTP errors that should trigger fallback avoid calling failConnection
immediately, allowing the SSE transport to be attempted as expected.

---------

Co-authored-by: Glen Maddern <glen@glenmaddern.com>
This commit is contained in:
Glen Maddern 2025-07-01 12:14:32 +10:00 • committed by GitHub
commit fe65d50ec3
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -369,9 +369,10 @@ export function useMcp(options: UseMcpOptions): UseMcpResult {
}
// Handle other connection errors
// Use stable failConnection
// For HTTP transport, consider fallback only for specific error types
// "Not connected" errors should still be treated as failures, not fallback triggers
failConnection(`Failed to connect via ${transportType.toUpperCase()}: ${errorMessage}`, errorInstance)
return 'fallback' // If our logic above is wrong, we'd prevent HTTPs servers from ever working. So always fall back as a last resort.
return 'failed'
}
} // End of tryConnectWithTransport helper
@ -392,10 +393,18 @@ export function useMcp(options: UseMcpOptions): UseMcpResult {
// Auto mode - try HTTP first, fallback to SSE
addLog('debug', 'Using auto transport mode (HTTP with SSE fallback)')
const httpResult = await tryConnectWithTransport('http')
// 2. Try SSE only if HTTP requested fallback and we haven't failed/redirected
if (httpResult === 'fallback' && isMountedRef.current && stateRef.current !== 'failed' && stateRef.current !== 'authenticating') {
// Try SSE only if HTTP requested fallback and we haven't redirected for auth
// Allow fallback even if state is 'failed' from a previous HTTP attempt in auto mode
if (httpResult === 'fallback' && isMountedRef.current && stateRef.current !== 'authenticating') {
addLog('info', 'HTTP failed, attempting SSE fallback...')
const sseResult = await tryConnectWithTransport('sse')
finalStatus = sseResult // Use SSE result as final status
// If SSE also failed, we need to properly fail the connection since HTTP didn't call failConnection
if (sseResult === 'failed' && isMountedRef.current) {
// SSE failure already called failConnection, so we don't need to do anything else
}
} else {
finalStatus = httpResult // Use HTTP result if no fallback was needed/possible
}