Is there a recovery mechanism for AcceptAsync failures I'm missing?

[Vivian5510]

Question: Is there a recovery mechanism for AcceptAsync failures I'm missing?

Hi Garnet team and community! 👋

I'm studying the Garnet source code to better understand its network architecture, and I came across something in
the TCP accept logic that I'm not sure I understand correctly. I'm hoping someone can help clarify whether this
is intentional design or if I'm missing something.

What I'm Looking At

In libs/server/Servers/GarnetServerTcp.cs, I see this accept pattern:

private void AcceptEventArg_Completed(object sender, SocketAsyncEventArgs e)
{
    try
    {
        do
        {
            if (!HandleNewConnection(e)) break;  // 🤔 This breaks the loop
            e.AcceptSocket = null;
        } while (!listenSocket.AcceptAsync(e));
    }
    catch (ObjectDisposedException) { }
}

private bool HandleNewConnection(SocketAsyncEventArgs e)
{
    if (e.SocketError != SocketError.Success)
    {
        e.Dispose();
        return false;  // 🤔 This causes the break above
    }
    // ... rest of the method
}

My Question

From what I can see, if AcceptAsync returns any SocketError (like TooManyOpenSockets, NetworkDown, etc.), the
accept loop exits permanently. The server process keeps running because of Thread.Sleep(Timeout.Infinite) in the
main thread, but it seems like it would stop accepting new connections.

Am I missing something here? Is there:

1. A higher-level restart mechanism I haven't found?
2. Some other code path that handles accept failures?
3. A monitoring system that detects and recovers from this state?
4. An assumption that such errors shouldn't happen in practice?

What I've Searched

I've looked through:
- GarnetServerMonitor.cs - but it seems to only track successful connections
- Various background tasks and timers - didn't find accept recovery logic
- Cluster and failover code - seems focused on data replication, not network layer

Why I'm Curious

In production environments, temporary SocketErrors can happen due to:
- Resource exhaustion (too many open files/sockets)
- Network interface resets
- OS-level network stack issues

Most server implementations I've seen either retry these operations or at least log/monitor them. But I might be
missing where Garnet handles this.

Environment

- Looking at the latest code on main branch
- Specifically interested in single-node scenarios

Is this normal behavior?

Is this the expected design? Should operators monitor for this condition externally? Or am I completely
misunderstanding how this code works?

Any insights would be really helpful! I'm trying to understand Garnet's resilience patterns better.

Thanks! 🙏

Note: I'm asking this in Discussions rather than Issues because I want to make sure I understand the design
correctly before assuming anything is wrong.