Skip to content

fix: use the shared WebSocket URL helper in slides and workshop pages - #622

Open
lbarrosby wants to merge 1 commit into
AsyncFuncAI:mainfrom
lbarrosby:fix/ws-url-slides-workshop
Open

lbarrosby wants to merge 1 commit into
AsyncFuncAI:mainfrom
lbarrosby:fix/ws-url-slides-workshop

Conversation

@lbarrosby

Copy link
Copy Markdown
Contributor

The slides and workshop pages open their WebSocket with:

const serverBaseUrl = process.env.SERVER_BASE_URL || 'http://localhost:8001';
const wsBaseUrl = serverBaseUrl.replace(/^http/, 'ws') ? serverBaseUrl.replace(/^https/, 'wss') : ...;

SERVER_BASE_URL is not a NEXT_PUBLIC_ variable, so in the browser this is always http://localhost:8001, and the ternary is always truthy, so an http base never becomes ws. On any deployment not opened from localhost these pages try the viewer's own machine, wait for the timeout and only then fall back to /api/chat/stream. Behind a reverse proxy they also ignore NEXT_PUBLIC_WS_BASE_URL.

Chat and codemap already solved this in src/utils/websocketClient.ts. This exports getWebSocketUrl() from there and uses it in both pages, so all WebSocket callers resolve the URL the same way (page host + NEXT_PUBLIC_API_PORT, or NEXT_PUBLIC_WS_BASE_URL).

Refs #389

Tested: tsc --noEmit passes. node -e with the old expression gives http://localhost:8001/ws/chat for the default value.

These pages built the URL from SERVER_BASE_URL, which is not exposed
to the browser, so they always targeted localhost:8001 (and kept the
http scheme). Reuse getWebSocketUrl() like chat and codemap, so they
follow the page host, NEXT_PUBLIC_API_PORT and NEXT_PUBLIC_WS_BASE_URL.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant