Skip to content

Close socket if handle_init returns an :error#18

Open
maxsalven wants to merge 6 commits into
absinthe-graphql:mainfrom
wodup:main
Open

Close socket if handle_init returns an :error#18
maxsalven wants to merge 6 commits into
absinthe-graphql:mainfrom
wodup:main

Conversation

@maxsalven

Copy link
Copy Markdown

The current docs suggest returning {:error, %{}, socket} from handle_init.
https://github.com/geometerio/absinthe_graphql_ws/blob/b98d3deb15febd856725f69b7a54c38e3b67ab3b/lib/absinthe/graphql_ws/socket.ex#L176-L178

This ends up creating an invalid error message:
https://github.com/geometerio/absinthe_graphql_ws/blob/b98d3deb15febd856725f69b7a54c38e3b67ab3b/lib/absinthe/graphql_ws/transport.ex#L129-L130
https://github.com/geometerio/absinthe_graphql_ws/blob/b98d3deb15febd856725f69b7a54c38e3b67ab3b/lib/absinthe/graphql_ws/message/error.ex#L9-L11

The error message will be type: "error", id: %{}, payload: %{}, when the spec expects the id to be a string, and payload to be an array of graphql errors. The client currently throws an error when it sees this invalid message.

Even if you fix this, the spec does not expect an error message in response to connection_init, and the official client will also throw an error.

The reference implementation closes the connection with code 4403 if handling connection_init fails:
https://github.com/enisdenjo/graphql-ws/blob/799cfc7bbe0f6d1a5c90b4880f02c58c5c3a06d4/src/server.ts#L612-L614

https://github.com/enisdenjo/graphql-ws/blob/799cfc7bbe0f6d1a5c90b4880f02c58c5c3a06d4/src/__tests__/server.ts#L437-L458

This is critical for token refresh based workflows (e.g. the token you included in connectionParams on the client is stale, and you need to check for 4403 Forbidden to refresh it).

This PR matches the spec. I'm not sure how to adapt the tests to check for this, suggestions welcome!

@jHwls

jHwls commented Dec 3, 2022

Copy link
Copy Markdown

@maxsalven this is a good fix. Thank you! Just bumping in the hopes it gets picked up.

Might also be good to be able to pass a custom error code? vs just defaulting to 4403

@maartenvanvliet

Copy link
Copy Markdown
Contributor

+1 for this fix.

The graphql errors in the payload array is interesting. Since this is just protocol negotiation and no graphql has been invoked yet it does not make much sense to return graphql errors. If an empty array is passed ([]) as payload instead of {} does the client accept it?

@mdoverhag

Copy link
Copy Markdown

This would be a great improvement. I was mostly surprised to see the connection was left open when returning a {:error, %{error: "unauthorized"}, socket} in the handle_init/2 callback.

bolek added a commit to tolemi-inc/absinthe_graphql_ws that referenced this pull request Mar 7, 2025
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.

4 participants