Summary

When deploying OpenHands behind a reverse proxy that routes /runtime/{port}/... requests to agent-server containers, the V1 WebSocket connection fails because buildWebSocketUrl() only extracts the host from conversationUrl, losing the required path prefix.

Example:

• conversationUrl: https://example.com/runtime/55313/api/conversations/abc123
• Before: wss://example.com/sockets/events/abc123 ❌ (request goes to main app, not agent-server)
• After: wss://example.com/runtime/55313/sockets/events/abc123 ✅ (correctly routed to agent-server)

Changes

1. Added extractPathPrefix() helper function - Extracts the path before /api/conversations from the conversation URL (e.g., /runtime/55313)

2. Updated buildWebSocketUrl() - Now includes the path prefix when building WebSocket URLs

3. Updated buildHttpBaseUrl() - Also includes path prefix for consistency with other API calls

4. Added comprehensive unit tests - Tests cover all scenarios including:

   • Standard URLs without path prefix
   • Proxy deployment URLs with path prefix
   • Fallback behavior for invalid/missing URLs

Context

This fix aligns V1 WebSocket behavior with the existing V0 socket.io provider in ws-client-provider.tsx, which correctly handles path prefixes:

// V0 implementation that works correctly
const pathBeforeApi = u.pathname.split("/api/conversations")[0] || "/";
socketPath = `${pathBeforeApi.replace(/\/$/, "")}/socket.io`;

Test Plan

• Unit tests added for all affected functions
• Verified WebSocket connection works in proxy deployment environment
• Tested standard deployment (without path prefix) still works

Related Issues

Fixes #12283
Related to #12271 (App View never worked - same root cause for port accessibility)