fix(tests): мок-сервер переставал принимать соединения после одного обрыва

[Platonenkov]

Summary

Чинит флейк TestConcurrentChangeServerKeepsClientRecoverable, из-за которого unit упал на push-прогоне dev (run 31613419252), тогда как тот же коммит в PR-прогоне прошёл. Это единственная красная галка, оставшаяся на релизном PR #76.

Виноват не клиент, а мок-сервер.

Причина

Server.connectionCallback перезапускал приём соединений последней строкой try-блока:

OnClientConnected(this, new OnClientConnectedHandler(client));

// Start to accept incomming connections again
GetSocket().BeginAccept(connectionCallback, null);   // ← только если выше ничего не бросило
}
catch (Exception Exception)
{
    Debug.WriteLine("An error has occured while trying to accept a connecting client.\n\n{0}", Exception.Message);
}

Любое исключение выше по телу колбэка — и BeginAccept не вызывается уже никогда: приём соединений обрывается навсегда. Пир, рвущий соединение во время handshake, попадает ровно туда — clientSocket.Receive бросает Connection reset by peer, а конкурентные ChangeServer/Disconnect в тесте такие обрывы и порождают.

Почему это читалось как баг клиента: слушающий сокет остаётся связанным. Порт числится занятым, TCP-соединения ядро принимает в backlog, connect со стороны клиента успешен — и дальше тишина. Клиент ждёт handshake до своего таймаута и ретраится, пока не выйдет 30-секундное окно теста. Отсюда 2m06s у упавшего прогона против 10s у обычного и сообщение, обвиняющее клиент в том, что он «не дошёл до живого сервера», — при том что сервер к этому моменту оглох.

Строка Connection reset by peer: An error has occured while trying to accept a connecting client в CI-логе — это она и есть.

Доказательство

Локально флейк не воспроизвёлся ни разу за 12 прогонов подряд, поэтому доказательство построено не на статистике, а на прямом тесте дефекта: соединение рвётся на handshake через LingerOption(true, 0) (тот самый RST), после чего обычный клиент обязан подключиться.

	до фикса	после
TestAbortedHandshakeLeavesTheMockAccepting	❌ 8s	✅
TestRepeatedAbortedHandshakesLeaveTheMockAccepting	❌ 2s	✅

Оба падения — с той же строкой в выводе, что в CI. После фикса оба проходят за 0.6s суммарно.

Фикс

• BeginAccept перезапускается безусловно после колбэка, чем бы тот ни кончился
• ObjectDisposedException обрабатывается отдельно и без перезапуска: он означает, что Stop() закрыл listener, и повторная попытка только бросит снова
• сокет, чей handshake упал, закрывается, а не течёт до конца процесса

Чтобы это не повторилось диагностически

TestUtils.MockCompletesHandshake пробует настоящий WS-upgrade и проверяет ответ 101; упавший reconnect-тест теперь вызывает её и пишет результат в сообщение — глухой мок больше не будет прочитан как баг клиента.

Обычный TCP-connect для такой пробы не годится: против связанного, но не принимающего сокета он успешен и не доказывает ничего — ровно в эту ловушку всё и провалилось. Сама проба покрыта тремя случаями: живой мок, свободный порт и слушающий сокет, который никогда не принимает.

Проверка

• 905 юнит-тестов зелёные
• TestUReconnectSessionRaces — 10 прогонов подряд без падений
• новые тесты падают на старом колбэке и проходят на новом

Затронута только тестовая инфраструктура — код SDK не менялся.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8473dfdd-e139-4a7d-afe3-b4dbb50bc6da

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}