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
Add utility method to get the websocket pattern #10520
Comments
Sounds like a useful enhancement. Would you like to work on this feature @jmcdo29? |
I'll need some insight in where the contract gets created on request, but one I have that I think I should be okay |
I think I got something working. @kamilmysliwiec we don't bind an exception filter for invalid events like we do the 404 handler in HTTP, right? |
Could you clarify what you mean by invalid events? 🤔 Emitting events for which there are no corresponding handlers? If so, yes, we do not |
Correct, events for which there are no |
Let's track this issue here #10545 🙌 |
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Right now, the only way to get the current pattern being triggered for a websocket request is to do so via reflection and reading the metadata set by the
@SubscribeMessage()
decorator, which is okay for an interceptor, but unusable in a filter as there is noExecutionContext#getClass()
orExecutionContext#getHandler()
in filters.Describe the solution you'd like
Just like the RPC contexts have specific helper methods added to their
ArgumentsHost#switchToHrpc().getClient()
result to get the current pattern (e.g. MQTT ->getTopic()
, NATS ->getSubject()
, etc) it would be helpful for theArgumentsHost#switchToWs().getClient()
had a utility method to get the current message pattern. Maybe specificallygetPattern()
?Teachability, documentation, adoption, migration strategy
We can mention it in the docs on either the
exception filters
,guards
, orinterceptors
page, or create a new page about theWsExecutionContext
so that it's better documented. Adoption would be by those who are building something like I am. No migration strat needed, it should theoretically be a non-breaking change.What is the motivation / use case for changing the behavior?
I'm working on improving functionality for ogma so that it can log exceptions from the filter that aren't previously logged via its interceptor. HTTP, GQL, and RPC, this is all doable with minor modifications I'm just stuck on the implementation for WS because of the lack of ability to get this value. It would be possible with custom ws and socket.io adapters that bind middleware, but it would be much nicer to not have to have devs use anything other than what my package provides.
The text was updated successfully, but these errors were encountered: