How the Client Connects

The client receives events from the server while it maintains a long-lived connection. CometD performs the handshake, connection, and reconnection requests. Your custom code performs other operations, such as subscription. The client reconnects for the following conditions.

After Receiving Events

If the client receives events, the client must reconnect immediately using CometD to receive the next set of events. If the reconnection doesn't occur within 40 seconds, the server expires the subscription, and the connection closes. The client must start over with a handshake and subscribe again using your custom /meta/handshake channel listener.

When No Events Are Received

If no events are generated while the client is waiting and the server closes the connection, CometD must reconnect within 110 seconds. The Bayeux server sends a response to the client that contains the reconnect deadline of 110 seconds in the advice field. If the client doesn't reconnect within the expected time, the server removes the client's CometD session.

After a Network Failure

If a long-lived connection is lost due to unexpected network disruption, CometD attempts to reconnect. If this reconnection is successful, clients must resubscribe, because this new connection has gone through a rehandshake that removes previous subscribers. Clients can listen to the /meta/handshake meta channel to receive notifications when a connection is lost and reestablished. For more information, see Short Network Failures and Long Network Failures or Server Failures in the CometD Reference Documentation.

After a Disconnect Message is Received

If the client disconnects the subscription, it receives a response on the /meta/disconnect channel. The response includes the successful field with a value of true or false, which indicates whether the client request was successfully processed or not. The client can add a listener to the /meta/disconnect channel to process the response.

In Streaming API version 64.0 and later, the server can sometimes send a disconnect message to the client. The disconnects, which happen more frequently when using a Hyperforce instance, are due to infrastructure auto-scaling. To keep the subscription active, the client must reconnect to the Streaming API endpoint. To reconnect, the client must add a listener for the /meta/disconnect channel and reconnect after receiving a disconnect message. For details, see the CometD reference documentation.

After Invalid Authentication

Client authentication can sometimes become invalid, for example, when the OAuth token is revoked or the Salesforce session is invalidated by a Salesforce admin. Streaming API regularly validates the OAuth token or session ID while the client is connected. If client authentication is not valid, the client is notified with the 401::Authentication invalid error and an advice field containing reconnect=none. After receiving the error notification in the channel listener, the client must reauthenticate and reconnect to receive new events.

Invalidated client authentication doesn’t include Salesforce session expiration. The Salesforce session never expires in a CometD client. Salesforce keeps extending the timeout interval as long as the client stays connected.

Note

This diagram shows how a CometD client connects to Salesforce after it encounters an authentication error.

For details about these steps, see Bayeux Protocol, CometD, and Long Polling.