Add utility method to get the websocket pattern

[jmcdo29]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

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 no ExecutionContext#getClass() or ExecutionContext#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 the ArgumentsHost#switchToWs().getClient() had a utility method to get the current message pattern. Maybe specifically getPattern()?

Teachability, documentation, adoption, migration strategy

We can mention it in the docs on either the exception filters, guards, or interceptors page, or create a new page about the WsExecutionContext 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.

[kamilmysliwiec]

Sounds like a useful enhancement. Would you like to work on this feature @jmcdo29?

[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

[jmcdo29]

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?

[kamilmysliwiec]

@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

[jmcdo29]

@kamilmysliwiec we don't bind an exception filter for invalid events like we do the 404 handler in HTTP, right?

Emitting events for which there are no corresponding handlers? If so, yes, we do not

Correct, events for which there are no @SubscribeMessage() handlers

[kamilmysliwiec]

Let's track this issue here #10545 🙌