-
Notifications
You must be signed in to change notification settings - Fork 886
chore: consolidate websocketNetConn implementations #12065
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @spikecurtis and the rest of your teammates on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be nice to see a test that the 4MiB payload works. Perhaps we could use functional options to adjust it if needed and then test that it works/errors with different sizes.
@@ -50,7 +50,7 @@ func TestTailnetAPIConnector_Disconnects(t *testing.T) { | |||
if !assert.NoError(t, err) { | |||
return | |||
} | |||
ctx, nc := websocketNetConn(r.Context(), sws, websocket.MessageBinary) | |||
ctx, nc := WebsocketNetConn(r.Context(), sws, websocket.MessageBinary) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to fix this bad use of r.Context()
since someone could look at this and get the wrong idea. (The websocket.Accept
invalidates r.Context()
cancellation.)
ctx, nc := WebsocketNetConn(r.Context(), sws, websocket.MessageBinary) | |
ctx, nc := WebsocketNetConn(context.Background(), sws, websocket.MessageBinary) |
I know some other places are using r.Context()
via ctx := r.Context()
too, but this one just seems too explicitly wrong. 😄
Perhaps this is actually a case for moving websocket.Accept
into codersdk.WebsocketNetConn
as well (or creating a unified function, codersdk.WebsocketAcceptNetConn
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The websocket.Accept invalidates r.Context() cancellation.
I don't understand what it means to "invalidate" a context cancelation.
Are you referring to the idea that once we have a websocket, passing r.Context()
is a bit pointless because the context won't get canceled before the underlying TCP connection is closed? I guess that's true enough, but changing it to context.Background()
doesn't change anything from a functional standpoint.
Are you suggesting we don't accept a context at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The context is actually not even tied to the TCP connection, it is tied to the handler which creates a scenario where it’s unlikely to ever be cancelled in a way that matters.
https://pkg.go.dev/net/http#Hijacker
Functionally, you’re right, there’s no difference but this behavior can easily trip anyone up so its usage should be discouraged.
89920d9
to
99b8467
Compare
Merge activity
|
Consolidates websocketNetConn from multiple packages in favor of a central one in codersdk