Websocket API gateway $disconnect event reliability

0

Anyone know how reliable the $disconnect event for a websocket API Gateway is? The documentation states:

The connection can be closed by the server or by the client. As the connection is already closed when it is executed, $disconnect is a best-effort event. API Gateway will try its best to deliver the $disconnect event to your integration, but it cannot guarantee delivery.

What does this mean, in practice? Do we assume that the $disconnect event is completely unreliable and implement accordingly? Or is it closer to something like "we can expect the $disconnect event 99.9% of the time, but there is the small chance that it may not come through"?

The wording of the documentation is somewhat vague, so trying to get more information.

Thanks!

1 Answer
0

The $disconnect event in WebSocket API Gateway is indeed not guaranteed to be 100% reliable, but it's important to understand the context and implications of this "best-effort" delivery.

In practice, the $disconnect event is generally quite reliable, but there are scenarios where it might not be delivered. This can happen due to various reasons such as network issues, sudden client disconnections, or server-side problems.

The "best-effort" nature means that API Gateway will attempt to deliver the $disconnect event to your integration in most cases, but there's no absolute guarantee. This is primarily because the connection is already closed when the $disconnect event is triggered, making it impossible to ensure delivery in all scenarios.

While exact reliability percentages aren't provided, it's reasonable to expect that the $disconnect event will be delivered in the vast majority of cases. However, it's crucial to design your application with the understanding that there might be rare instances where the event isn't received.

Given this, it's advisable to implement your application logic with some redundancy:

  1. Rely on the $disconnect event for most cases, as it will likely be delivered.
  2. Implement additional mechanisms to handle cases where the $disconnect event might not arrive. This could include periodic checks for stale connections or implementing timeouts.

For critical applications where connection state is crucial, you might want to implement additional logging or monitoring to track any discrepancies between expected and actual disconnections.

Remember, the backend can also initiate disconnection using the @connections API, which provides more control over the disconnection process when initiated from the server side.

In summary, while the $disconnect event is generally reliable, it's wise to design your application with the understanding that in rare cases, it might not be delivered. This approach ensures robustness in your WebSocket API implementation.
Sources
Manage connected users and client apps: $connect and $disconnect routes - Amazon API Gateway
API Gateway WebSocket APIs - Amazon API Gateway
Create routes for WebSocket APIs in API Gateway - Amazon API Gateway

answered 8 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions