fix(websocket): path handling when merging template & target URLs#7290
Merged
dwisiswant0 merged 1 commit intodevfrom Mar 24, 2026
Merged
fix(websocket): path handling when merging template & target URLs#7290dwisiswant0 merged 1 commit intodevfrom
dwisiswant0 merged 1 commit intodevfrom
Conversation
Contributor
WalkthroughFixed a double path concatenation bug in WebSocket URL handling where paths were being incorrectly joined twice. Now the path is only replaced when the base path is empty or root ( Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
pkg/protocols/websocket/websocket.go (1)
311-312:⚠️ Potential issue | 🟠 MajorBinary websocket writes remain blocked by hardcoded text opcode.
Line 311 always uses
ws.OpText, preventing binary payload transmission from templates. TheInputstruct (lines 78–92) has no frame-type selector field, and there are no send-path binary tests. Issue#5028is only partially addressed.💡 Suggested fix (add explicit frame type with backward-compatible default)
type Input struct { @@ Data string `yaml:"data,omitempty" json:"data,omitempty" jsonschema:"title=data to send as input,description=Data is the data to send as the input"` + // Type is the websocket frame type for this input (text or binary). + // examples: + // - value: "\"text\"" + // - value: "\"binary\"" + Type string `yaml:"type,omitempty" json:"type,omitempty" jsonschema:"title=websocket frame type,description=Frame type for payload,enum=text,enum=binary"` @@ - err = wsutil.WriteClientMessage(conn, ws.OpText, finalData) + opcode := ws.OpText + if strings.EqualFold(req.Type, "binary") { + opcode = ws.OpBinary + } + err = wsutil.WriteClientMessage(conn, opcode, finalData)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pkg/protocols/websocket/websocket.go` around lines 311 - 312, The write path always uses ws.OpText (wsutil.WriteClientMessage(conn, ws.OpText, finalData)), blocking binary frames; add a frame-type selector to the Input struct (e.g., FrameType string or FrameOp int) with a backward-compatible default of text, update the send logic in the function that writes finalData to choose ws.OpBinary when the Input.FrameType indicates binary (otherwise use ws.OpText), and add/adjust tests to cover binary payload transmission through wsutil.WriteClientMessage and the new Input frame selection behavior.
🧹 Nitpick comments (1)
pkg/protocols/websocket/websocket_test.go (1)
13-26: Avoid duplicating production path-resolution logic inside test helper.
resolveAddressmirrors implementation logic line-for-line, so the test can pass even if both are wrong in the same way. Prefer calling a shared exported/internal resolver fromwebsocket.goto keep a single source of truth.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pkg/protocols/websocket/websocket_test.go` around lines 13 - 26, The test helper duplicates production logic in resolveAddress; remove this local helper and call the shared resolver implemented in websocket.go (e.g., the exported/internal ResolveAddress or the package-level resolveAddress in websocket.go) so the test uses the same implementation as production; update imports/tests to reference that function, delete the duplicate resolveAddress in websocket_test.go, and adjust any call sites in the tests to use the shared symbol (ResolveAddress/resolveAddress) so there is a single source of truth for path-resolution.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@pkg/protocols/websocket/websocket.go`:
- Around line 311-312: The write path always uses ws.OpText
(wsutil.WriteClientMessage(conn, ws.OpText, finalData)), blocking binary frames;
add a frame-type selector to the Input struct (e.g., FrameType string or FrameOp
int) with a backward-compatible default of text, update the send logic in the
function that writes finalData to choose ws.OpBinary when the Input.FrameType
indicates binary (otherwise use ws.OpText), and add/adjust tests to cover binary
payload transmission through wsutil.WriteClientMessage and the new Input frame
selection behavior.
---
Nitpick comments:
In `@pkg/protocols/websocket/websocket_test.go`:
- Around line 13-26: The test helper duplicates production logic in
resolveAddress; remove this local helper and call the shared resolver
implemented in websocket.go (e.g., the exported/internal ResolveAddress or the
package-level resolveAddress in websocket.go) so the test uses the same
implementation as production; update imports/tests to reference that function,
delete the duplicate resolveAddress in websocket_test.go, and adjust any call
sites in the tests to use the shared symbol (ResolveAddress/resolveAddress) so
there is a single source of truth for path-resolution.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: cec8e0a4-ae0f-4aa2-8267-2ca133a33581
📒 Files selected for processing (2)
pkg/protocols/websocket/websocket.gopkg/protocols/websocket/websocket_test.go
dwisiswant0
changed the title
dwisiswant0
approved these changes
Mar 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposed changes
Close #5028
Checklist
Summary by CodeRabbit