Per Prameet's explanation, the GoogleApiClient will first call onConnectionSuspended and then either onConnected if the Cast SDK managed to reconnect or onConnectionFailed otherwise.

We then wondered how the Presentation API should behave while the network connection is  in suspended state:
- pretend the connection is connected until we know for sure it failed - that would probably mean keeping track of all pending messages sent through the Presentation API during this time
- report 'disconnected' state and disconnect from the Cast device even if the reconnection succeeded
- report 'connecting' state and reject any messages sent in this state
- introduce a 'suspended' state if 'connecting' is not good enough?

+Mark,Vadim for their thoughts. How does Chrome handle such situations on desktop?

+Bin who has been working on connection states.

Ping Anton; is this still something we need in M57?

Re: Comment 1

There's no "suspended" state in the Presentation API.  If the message cannot be delivered the connection fires an error event and enters a terminal error state.  The page will need to reconnect when the network is available.  The MRP could decide to implement queueing/retries and keep the connection "connected" even if it really isn't, but that leads to weird behaviors like a pause command getting sent minutes after the user gesture, so I wouldn't recommend it.

Moving to the backlog as it looks like this won't be done for M57.

So the resolution is to report the connection as "disconnected" then? That'd be easier to implement then queuing the messages until the connection is restored while maybe degrading the UX.

Do we know if these intermittent failures happen often during a typical session and how often and how fast they recover?

To avoid weird behaviors we could queue the commands for a few seconds and then report disconnection, for example.

+Shen whose team would fix this.

There's no "disconnected." The connection would transition to "closed" with a closeReason of "error".

https://w3c.github.io/presentation-api/#interface-presentationconnectioncloseevent

I misspoke about the error event.  That has been replaced by closeReason = error.

If the SDK wants to craft some specific behavior for a connection in a suspended state, i.e. queue on the page side and reconnect later, they could set a specific message for the close event.