You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that using sinks to match a WebSocket request is currently undocumented, and it leads to sloppy behaviour/mismatched typing, although it surprisingly works, in a sense. But the sink then receives a ws object instead of resp, so a sink method that is unaware of the possibility will likely just error out when trying to set unexpected attributes on ws.
A decision is needed how we want this to work, and what can be considered a fix, and not a breaking change.
OTOH, we have clearly documented the sink callable in add_sink() as taking req and resp parameters, so I think we can afford some redesign here. Alternatively, we could add a flag governing this behaviour.
One way to architect this is to add a ws parameter along the lines of App.add_error_handler(). However, sinks can accept arbitrary **kwargs...
The text was updated successfully, but these errors were encountered:
It seems that using sinks to match a WebSocket request is currently undocumented, and it leads to sloppy behaviour/mismatched typing, although it surprisingly works, in a sense. But the sink then receives a
ws
object instead ofresp
, so a sink method that is unaware of the possibility will likely just error out when trying to set unexpected attributes onws
.A decision is needed how we want this to work, and what can be considered a fix, and not a breaking change.
OTOH, we have clearly documented the sink callable in
add_sink()
as takingreq
andresp
parameters, so I think we can afford some redesign here. Alternatively, we could add a flag governing this behaviour.One way to architect this is to add a
ws
parameter along the lines ofApp.add_error_handler()
. However, sinks can accept arbitrary**kwargs
...The text was updated successfully, but these errors were encountered: