Document WS_ENDPOINT in .env.sample for local dev#3166
Conversation
Without WS_ENDPOINT set, the realtime websocket URL is derived from API_ENDPOINT via a replace that only rewrites the production 'https://api...' host. A localhost API then yields an insecure 'ws://localhost' URL that the CSP connect-src (wss: only) blocks, so live wave updates silently fail in local dev. Documenting the var spares developers that confusion. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: brookr <11095+brookr@users.noreply.github.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds documented ChangesWebSocket endpoint configuration
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
6529bot general PR review - f3c6ecdVerdict: Good to merge Documentation-only change to One minor note: the comment states CSP allows |
6529bot WCAG 2.2 AA analysis - f3c6ecdVerdict: No WCAG findings Documentation-only change to |
6529bot i18n analysis - f3c6ecdVerdict: No i18n findings Documentation-only change to |
6529bot crypto security analysis - f3c6ecdVerdict: No security findings Documentation-only change to |
6529bot GLM Swarm ReviewVerdict: Advisory only This GLM swarm review is advisory and complements, not replaces, existing tests and reviewbots. Important
Nice-to-have
Testing feedback loop
|
6529bot responsiveness review - f3c6ecdVerdict: Responsive checks passed Root Cause / Summary All 32 checks passed across four contexts with zero deterministic failures, zero blank screenshots, and Blocking Findings None. No deterministic failures, no blank/near-white evidence ( Non-Blocking Findings
Platform Coverage
No blocking issues found; the run is clean and ready to merge from a responsiveness standpoint. Screenshot evidence: native-mobile /the-memes, native-mobile /meme-lab, native-mobile /rememes, native-mobile /network, native-mobile /waves, native-mobile /, native-mobile /meme-calendar, native-mobile /discover, electron-desktop /rememes, web-mobile /the-memes, web-desktop /meme-lab, web-desktop /the-memes and 20 more in the details. Deterministic responsiveness detailsVerdict: Responsive checks passed
Responsiveness runner summary6529bot Responsiveness SummaryStatus: pass Platform Context
Platform Matrix
Warnings
Slowest Checks
|
6529bot follow-up commit review - c301ed2Verdict: No new findings The commit set is unchanged from the previously reviewed head ( The one open question worth confirming (raised previously by the general review and GLM swarm) remains: whether the derived |
6529bot follow-up commit review - ab37473Verdict: No new findings The diff since the prior same-lane marker ( The one open verification item carried from earlier reviews still stands and is not a defect in this diff: confirm whether the |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.env.sample:
- Around line 6-9: Update the localhost WebSocket guidance in the environment
configuration so it accurately reflects the fallback behavior: localhost API
endpoints are passed unchanged to new WebSocket(), while only the production
https://api host is rewritten to wss://ws. Adjust the note in the surrounding
environment configuration without changing unrelated settings.
- Line 10: Remove the empty WS_ENDPOINT assignment from the sample environment
file and update its local-fallback note to match the actual behavior in
useWaveWebSocket, which only rewrites the documented api-to-ws host pattern; do
not imply that localhost API URLs are automatically converted to the websocket
host.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
CodeRabbit caught two problems: an uncommented empty WS_ENDPOINT= fails env validation when the sample is copied verbatim (the schema rejects empty strings and next.config fail-fasts), and the note claimed a CSP block when a localhost API_ENDPOINT actually reaches the WebSocket constructor unchanged and fails there. Signed-off-by: brookr <11095+brookr@users.noreply.github.com>
6529bot follow-up commit review - e3d3f9bVerdict: No new findings Resolved since last review
This also resolves the long-standing open verification item carried across prior lanes (CSP vs. constructor failure). The documentation now matches the described client behavior. No new issues introduced. |
6529bot follow-up commit review - c00df30Verdict: No new findings The diff since the prior same-lane marker ( The two CodeRabbit inline findings and the long-standing CSP-vs-constructor verification item were all resolved in |
6529bot follow-up commit review - 25f4701Verdict: No new findings The diff since the prior same-lane marker ( Both CodeRabbit inline findings (empty |
6529bot follow-up commit review - 5821274Verdict: No new findings The diff since the prior same-lane marker ( Both CodeRabbit inline findings (empty |
6529bot follow-up commit review - a0c2eaa6529bot follow-up commit reviewVerdict: No new findings The diff since the prior same-lane marker ( Both CodeRabbit inline findings (empty |
6529bot follow-up commit review - f10b65e6529bot follow-up commit reviewVerdict: No new findings The diff since the prior same-lane marker ( Both CodeRabbit inline findings (empty |
6529bot follow-up commit review - 656d7fc6529bot follow-up commit reviewVerdict: No new findings The diff since the prior same-lane marker ( Both CodeRabbit inline findings (empty |
6529bot follow-up commit review - 3409bd46529bot follow-up commit reviewVerdict: No new findings The diff since the prior same-lane marker ( Both CodeRabbit inline findings (empty |
6529bot follow-up commit review - bc800deVerdict: No new findings The diff since the prior same-lane marker ( Both CodeRabbit inline findings (empty |
|
6529bot follow-up commit review - 8c71130Verdict: No new findings The diff since the prior same-lane marker ( Both CodeRabbit inline findings (empty |
2 participants
Issue
WS_ENDPOINTisn't in.env.sample, so local dev typically leaves it unset. The realtime websocket URL then derives fromAPI_ENDPOINTvia.replace("https://api", "wss://ws"), which only rewrites the production host shape. A localhost API (http://localhost:3000) becomes an insecurews://localhost:3000URL, which the CSPconnect-src(wss:only, nows:) blocks — so live wave updates silently fail locally, with only a console CSP violation to hint at why.Fix
WS_ENDPOINT=entry to.env.sampleexplaining the production value and why to set it locally.Changes
.env.sample: one new documented var. No code.Validation
WS_ENDPOINTalready exists in the env schema (optional). No behavior change.Risk
Deployment
🤖 Generated with Claude Code
Summary by CodeRabbit
WS_ENDPOINTenvironment variable to the sample configuration.wss://...) and local development.API_ENDPOINTwhenWS_ENDPOINTis not set, and noted that some non-productionAPI_ENDPOINTvalues requireWS_ENDPOINTto work properly.WS_ENDPOINTby default to avoid validation failures when left empty.