It would be useful to have support for optional acknowledgements in Channels, similar to e.g. what Socket.IO has.
Hi can you elaborate a bit and motivate what would make this useful?
Imagine the case where you have a group chat that’s similar to Whatsapp and you want to have delivery receipts. Currently the broadcast call is best effort (good for most use cases), but in some cases you do want the ack.
What’s preventing you from sending an ACK? There’s a multitude of levels you could ack for: Receival at the server, the message been processed on the server, the message being broadcasted on pubsub, any listening channel having received the message from pubsub, the message having made it down to the client of the channel process, … What if there’s currently nobody listening.
Can you describe more what you’re going for? Ack in which direction? The client can keep a last_seen_id or similar and replay missed events. Note that TCP will not deliver the messages out of order to the client, so they either arrive, or the connection dies. On reconnect, the client sends the last thing it saw and the server catches them up, so we would need more concrete examples of the flows that are lacking. Note that phoenix channels has built in acknowledgments, ie chan.push("foo").receive("ok", resp => ...) with the channel doing {:reply, {:ok, %{...}} or {:noreply, ...
1 Like
In my use case/example it would be a client ack’ing a message sent, similar to what socket.io does. I have been able to piece this out with existing implementation, my suggestion was if more people have this need, perhaps this comes out of the box from the framework. Imagine e.g. there is an optional handle_in callback for message type “ack” that someone could implement.
