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
[ ] Regression
[ ] Bug report
[ x ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.
Current behavior
When a connected ClientGrpcProxy unsubscribes the Observable returned for an stream gRPC method the upstream connection stays untouched and the server continuous to send updates, even if no-one's listening.
Expected behavior
When the client unsubscribes it calls cancel() on the ClientReadableStream which triggers a cancelled event on the ServerWritableStream - receiving this ServerGrpc stops consuming it's Observable, so upstream Observables can react to this.
cancel() causes the server to return a 1 CANCELLED: Cancelled error, which should not be propagated, as the cancellation was initiated by user-code on the ClientGrpcProxy side.
Minimal reproduction of the problem with instructions
N/A
What is the motivation / use case for changing the behavior?
Having an reactive upstream polling ServerGrpc that only stops polling when the client diconnects
Environment
Nest version: 5.0.1
For Tooling issues:
- Node version: 8.9.4
- Platform: Mac
The text was updated successfully, but these errors were encountered:
I'm submitting a...
Current behavior
When a connected
ClientGrpcProxy
unsubscribes the Observable returned for an stream gRPC method the upstream connection stays untouched and the server continuous to send updates, even if no-one's listening.Expected behavior
When the client unsubscribes it calls
cancel()
on theClientReadableStream
which triggers acancelled
event on theServerWritableStream
- receiving thisServerGrpc
stops consuming it's Observable, so upstream Observables can react to this.cancel()
causes the server to return a1 CANCELLED: Cancelled
error, which should not be propagated, as the cancellation was initiated by user-code on theClientGrpcProxy
side.Minimal reproduction of the problem with instructions
N/A
What is the motivation / use case for changing the behavior?
Having an reactive upstream polling
ServerGrpc
that only stops polling when the client diconnectsEnvironment
The text was updated successfully, but these errors were encountered: