Issue with emitWithAck

[abdou6666]

Describe the bug
I'm encountering an issue with the Socket.IO Client (version 4.7.5) when using emitWithAck in environments with unstable network connections.

When the client is disconnected and then reconnects (e.g., due to a brief backend outage), the event that was sent using emitWithAck gets emitted multiple times — specifically, it is emitted once initially and then three more times (matching the number of retries configured).

This leads to the server receiving and processing the same event multiple times after reconnection.

---

Steps to reproduce

1. Start the Socket.IO client with the configuration shown below.
2. Emit an event using emitWithAck.
3. Pause the backend Docker container to simulate a network failure.
4. Unpause the container to simulate reconnection.
5. Observe that the event is emitted multiple times after reconnection.

---

Client configuration

{
  ackTimeout: 1000,
  retries: 3,
  // Manager options
  autoConnect: true,
  reconnection: true,
  reconnectionAttempts: 100,
  reconnectionDelay: 1000,
  reconnectionDelayMax: 5000,
  timeout: 20000,
  addTrailingSlash: true,
  transports: ["websocket", "polling"],
  upgrade: true,
  withCredentials: true
}

[abdou6666]

I guess this is the intended behavior although it would be nice if SocketIO manages the deduplication of requests from frontend the client.

[darrachequesne]

Hi!

When you use the retries option, the client indeed expects the event to be acknowledged by the server:

io.on("connection", (socket) => {
  socket.on("my-event", (cb) => {
    cb("got it");
  });
});

Else, it will try up to 1 + # of retries times, as you've noted.

Reference: https://socket.io/docs/v4/client-options/#retries

Is it the behavior that you are experiencing?

Regarding deduplication, I think that it should rather be handled by the user, for example by committing the event ID in the database, as part as the same transaction as the event handling, to ensure the event is handled exactly once by the server.

Please check the tutorial for a basic example: https://socket.io/docs/v4/tutorial/step-8#exactly-once

[abdou6666]

Hi @darrachequesne ,
Yes, I agree can handle deduplicating the requests on the backend using a UUID sent from the frontend. However, I’m struggling to see a valid reason for allowing the same request to be received 1 + x times (with retries). In my opinion, this behavior is prone to bugs unless someone has a deep understanding of how Socket.IO works under the hood.

This retry mechanism, especially when not properly acknowledged due to server load or network bottleneck, could lead to a thundering herd problem where multiple retries flood the server, compounding the initial issue.