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

Answer

When the remote peer never invokes the acknowledgment callback, the callback remains pending for the lifetime of the socket. Socket.IO does not enforce a timeout for acknowledgments, so the originating handler is retained until the socket closes or the application removes it.

Confirmed facts

• Socket.IO versions 2.x through 4.x do not define a built-in timeout for acknowledgments. The library treats the absence of a timeout as a deliberate design choice.
• A pending acknowledgment holds a reference to the callback and any closure data until it is called, the socket disconnects, or the application cleans it up.
• On a clean disconnect, the library clears pending acknowledgments. If the peer silently drops the connection, callbacks may stay pending until client-side logic acts.
• Acknowledgments are not supported for volatile events. A volatile emit with a callback will silently ignore the callback.
• The transport, WebSocket or HTTP long-polling, does not change the acknowledgment waiting logic.

Likely explanation

Without a timeout, repeated emits that never receive an ack can accumulate references. Under frequent disconnects or high event rates this can grow heap usage and keep promises unresolved. An aggressive application timeout can cause false positives; a missing cleanup on disconnect can leave stale callbacks.

Steps needed for this case

1. Wrap the acknowledgment in a Promise with a manual timeout and clear the timer when the ack arrives.
2. Track pending acks and cancel or reject them on the socket disconnect event.
3. Avoid using acknowledgments with volatile events. Use a custom confirmation if delivery feedback is required for fire-and-forget telemetry.

Verification

• Emit an event with an ack that the server never calls and confirm the client callback stays pending until timeout or disconnect.
• Monitor heap growth with repeated unacknowledged emits to confirm accumulation without cleanup.

Missing diagnostic detail

Do you currently differentiate timeout values by event type and transport, or use a single global timeout? The recommendation for thresholds changes with that.