-
Notifications
You must be signed in to change notification settings - Fork 22
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
Async Subscribe handler #382
Comments
That's a good point. I haven't thought about adding an async handler support for subscribing to Presence and Channel updates even thought there is one in the event emitter. Currently if you block inside the subscribe function it will be Ok as the websocket is an a separate thread and the updates will be processed but will wait to call the Subscribe handlers. If you don't care about order (which I think you do) you can just fire and forget the task like this Just to be on the safe side I added the following test to make sure messages are processed correctly with a long blocking handler.
I'm going to add it to the TODO list for the library. |
Thanks for the fast response, and an even bigger thanks for that test as the confirmation! I'll continue with the blocking calls as I do indeed care about the order. In case you are not using issues here on GitHub for the TODOs feel free to close this issue. |
Thanks @bddckr. I'll just leave this issue open until we get it resolved :) |
Pretty much exactly what was raised in #94, but that one seems to have been closed without any resolution to one part of the issue:
Currently there is no
Func<Message, Task> handler
support inIRealtimeChannel.Subscribe/Unsubscribe
.I'm fine with there not being any async API for
(Un)Subscribe
if doing "async over sync" is OK (read below), but I wonder if it's simply an oversight as there is one forIEventEmitter.On/Off
.I'd like to fetch some data from my backend based on the message coming in. In my particular case the message will basically either tell me the latest state of some backend model I'm "watching", or it will tell me "too much changed, you're better off to just fetch again". The fetching of course does some I/O, thus it's async.
Is an alternative solution to just do
GetAwaiter().GetResult()
in theSubscribe
handler to make it synchronous? I'm not a friend of "async over sync" (or the reverse), but I'm pretty sure no user of Ably's .NET API ever needs aSubscribe
handler to synchronize back onto the context Ably is calling their handler from, so we should be fine with Solution A in all cases.I'm primarily worried that I might accidentally block something on Ably's side here as long as my async I/O runs in the handler. Additionally I'd like to avoid having to manage my own Task queue for these
Subscribe
handler tasks - I'd have to link them to eachSubscribe
subscription to preventUnsubscribe
not cancelling the (potentially still queued or already running) tasks.Internal conv: Internal https://ably-real-time.slack.com/archives/C030C5YLY/p1705494514068369
┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: