Looking for help in getting my facts straight in a technical dispute I’m currently facing.
What I am hearing is that the Phoenix Channels implementation is basically free to silently drop push messages from server to client, given a fairly short window of client unavailability (5 seconds). I presume that’s based on a reading of https://hexdocs.pm/phoenix/channels.html#resending-client-messages, which as I understand it concerns client-to-server push messages.
Before I try (again) to make my case, I’m looking for confirmation that I understand the following things correctly or correction if I’ve got it wrong:
When a Phoenix server instance sends a message to a client, it will either successfully deliver the message or the socket will have disconnected. (In the disconnect case, it is not possible to determine which messages were transmitted and which were not. That is OK in our proposed design. We are prepared to re-establish state when reconnecting.)
The Phoenix server instance will not selectively transmit messages as long as it remains connected. (In other words, it would be a Bad Thing™ for us if a momentary delay in network availability could cause messages 1, 3, 5, and 6 to be sent while 2 and 4 would get silently dropped, unless the entire connection were terminated shortly thereafter.)
The counter to the above statements are being used as sufficient cause to discredit any other argument in favor of using Phoenix Channels.
I should note that in our application space, there is no need for client-to-server push messages, so if the timeout case can be provably constrained to client-to-server messages, that would suffice.
Thanks for any advice you can offer!