Open rafikiassumani-msft opened 1 year ago
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Support server to clients acks so that reliable messaging can be implemented more easily. This would only be when using
Clients.Client()
. I think we should go back to the SendAsync (fire and forget) InvokeAsync (wait for ack) naming pattern. That's the one sticking point.EDIT by @anurse: For clarity, this issue is tracking all work related to allowing values to be returned from client invocations. It also covers allowing the server to wait for a
void
-returning (orTask
-returning) client side method to complete.Work left for .NET 7
.On
methods, but client results likely makes it more likely to block on the client sideIHubContext
in the Hub, or if you have multiple waiting results for the same connections Hubs.OnConnectedAsync
because that's a special method that runs before the receive loop starts, we need to throw/unblock/warn etc. for thisInvokeAsync
with.All
,.Group
, etc.InvokeAsync
void result? Scenario, acks without needing a valueRawResult
allocates and copy the bytes which can be expensiveCancellationToken
into.On
methods and sendCancelInvocation
hub messages to clients