What happens when a Socket.IO acknowledgment callback is never invoked?

Background

Socket.IO supports event acknowledgments through callbacks on both client and server, yet the protocol does not define a timeout for these callbacks. Across versions 2.x through 4.x, if the remote peer disconnects or simply never calls the acknowledgment, the originating callback remains pending indefinitely unless the application implements its own timeout logic.

Constraints

The library treats the absence of a built-in timeout as a deliberate design choice to keep the protocol simple. However, this shifts the burden to developers, who must decide how long to wait, how to clean up unresolved promises, and whether the strategy differs between WebSocket and HTTP long-polling transports. The volatile flag adds another dimension: volatile events are dropped when the socket is not ready, but acknowledgments on volatile events are not supported at all.

Open questions

1. What patterns reliably prevent memory leaks from accumulating unresolved acknowledgment callbacks during frequent disconnects?
2. How should application-level timeout values be chosen to accommodate variable network latency without triggering false positives?
3. Does the lack of acknowledgment support for volatile events limit their usefulness for fire-and-forget telemetry that still desires delivery confirmation?