fix(webapp): keep playground chat requests same-origin#4193
Conversation
|
WalkthroughThis change modifies the playground chat resource base URL construction to prefer same-origin requests. In the browser, an origin variable now uses window.location.origin, falling back to apiOrigin when unavailable, and playgroundBaseURL is rebuilt using this origin instead of always defaulting to apiOrigin. A changelog entry was added documenting the fix for a "Failed to fetch" error previously encountered when sending messages in the agent playground chat in certain environments. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Problem
The agent playground chat builds its realtime transport baseURL from apiOrigin, but points it at a same-origin /resources/... dashboard route. When API_ORIGIN differs from APP_ORIGIN, the in/append POST goes cross-origin, fails the CORS preflight, and messages never reach the agent ("Failed to fetch").
It only reproduces where the two origins differ — not locally, where both default to localhost:3030.
Fixes #4149.
Fix
Build the base URL from window.location.origin (falling back to apiOrigin on SSR), so realtime traffic stays same-origin — the same approach AgentView.tsx already uses.
Testing
Typecheck passes. The CORS path only manifests when API_ORIGIN != APP_ORIGIN, so verify on test-cloud (can't reproduce locally).