-
Notifications
You must be signed in to change notification settings - Fork 346
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
Recreate WebSocket client when connectionParams
change during execution
#6335
Comments
How do we decide that connectionParams is changed? |
We'd probably have to store it together with the instantiated WS instance. TBH, I haven't thought about it in detail - I just investigated. |
Hey, we currently use This works well for the first request after starting Mesh and the parameters are proxied correctly, however the As I understand from the discussion that @enisdenjo triggered above, this is not currently supported in Mesh, and the current behaviour is to keep the Websocket instance shared. What would be the right approach then for this workflow? Should user authentication for websocket connections occur before reaching Mesh (i.e. in an API gateway?). Even so, there may be other parameters that need to be sent to the underlying services (i.e. multi-tenancy discriminators) which change per connection. |
@petrepatrasc We have encountered the same issue. How did you solve it? |
Also have the same issue |
Related #4305 (comment), repro: https://github.com/enisdenjo/graphql-mesh-apollo-sample.
The actual problem why the repro is failing is because the WebSocket instance in Mesh is instantiated during initialisation providing the
connectionParams
, and then that client instance is used during execution. If this weren't so, each subscription would create a new WebSocket connection itself - which is not ideal.Provide a way of re-creating the WebSocket instance when the
connectionParams
change.The text was updated successfully, but these errors were encountered: