Socket.io client and Node.js server: coordinating acknowledgment timeouts with disconnect cleanup

Integration boundary

I am designing the request/response layer between a Socket.io browser client and a Node.js server (Socket.io v4 assumed on both ends). The client emits events with an acknowledgment timeout, and the server performs work that may outlive that timeout. I need a consistent policy for what happens on each side when the acknowledgment expires or the connection drops mid-request.

Constraints and uncertainty

From the documented behavior, an acknowledgment timeout only invokes the client callback with an error; it does not signal the server to stop processing, and there is no built-in cancellation propagation comparable to AbortController. Separately, the heartbeat settings (pingInterval/pingTimeout) control when a silent connection becomes a disconnect, which is my trigger for cleaning up pending work and listeners. That leaves two independent timers racing: the per-emit acknowledgment timeout and the transport-level disconnect detection.

The unresolved part is how to keep server-side state consistent across both paths without leaking listeners or double-completing work, especially when the client reconnects and may retry the same request while the original server-side operation is still running.

Questions

1. Is there a documented or conventional pattern for correlating an acknowledgment timeout on the client with cancellation of the corresponding in-flight handler on the server, given that Socket.io itself does not propagate cancellation?
2. Should cleanup of pending acknowledgments and event listeners be keyed off disconnect alone, or is a separate application-level timeout recommended when pingTimeout is much longer than the acknowledgment timeout?
3. On client reconnect with a new socket id, what is the accepted way to make retried requests idempotent so a late server response from the previous socket cannot be applied twice?