4つの言語で出たエラーは、1本の鍵の取り違えだった — 審査を通った版だけが正しかった — 制作日誌 #42
経路アプリの課金画面で、値段が出ない利用者が6人いた。エラーは4つの言語で届いていたが、原因は1つ。差し替え配信の中身にだけ、隣のアプリの鍵が入っていた。しかも3週間前、逆向きに同じことをしていた。
毎朝、3つのアプリのエラーを集計したレポートが届く。10月13日の朝、その中に見慣れない行があった。
経路検索アプリで、課金画面の商品が取れないというエラーが6人分。しかも4つの言語で、それぞれ別の行として並んでいる。
4種類のエラーが同時に起きたように見えた。実際は1種類だった。
4つの行は、同じ1文の翻訳だった
エラー文を並べて読むと、どれも「商品を1つも取得できませんでした」という同じ意味だった。課金の仕組みを預けている外部サービスが返す文が、端末の言語設定に合わせて訳されて届いていただけだ。
集計は文字列ごとに数えるので、同じ失敗が言語の数だけ別の行になる。件数を見て「4つ問題がある」と読むと、4倍の手間で4つの原因を探しに行くことになる。まず文の意味をそろえ、何人に起きているかで数え直した。6人、原因は1つ。
鍵は、隣のアプリのものだった
課金画面は、起動時に外部サービスへ「このアプリで売っている商品を教えて」と問い合わせる。その問い合わせには、アプリごとに発行された公開用の鍵を付ける。鍵が違えば、サービスは「そのアプリにそんな商品は無い」と返す。
経路アプリの中身を取り出して鍵を確かめると、入っていたのは隣のタスク管理アプリの鍵だった。
3つのアプリは、同じコードから枝分かれさせて作っている。手元には作業場が3つあり、それぞれに設定ファイルがある。経路アプリの作業場の設定ファイルには、8月20日から、タスク管理アプリの鍵が書かれたままだった。枝分かれさせたときに、鍵だけが元のアプリのまま残っていた。
審査を通った版は、正しい鍵を持っていた
不思議なのは、8月20日から10月13日まで、54日間だれも困っていなかったことだ。
理由は、アプリの届け方が2通りあることにある。
| 届け方 | 鍵をどこから読むか | 結果 |
|---|---|---|
| ストアの審査を通して出す版 | 配信サービス側に登録した値 | 正しい鍵 |
| 審査を通さず中身だけ差し替える配信 | 手元の作業場の設定ファイル | 隣のアプリの鍵 |
審査に出す版は、配信サービス側に登録してある値を使って組み立てる。そちらには経路アプリの正しい鍵が入っていた。だから審査も通るし、ストアから入れた直後の利用者は普通に値段が見える。
一方、中身だけを差し替える配信は、手元で書き出した中身をそのまま送る。書き出す道具は手元の設定ファイルを読む。ここで初めて、54日間眠っていた取り違えが表に出た。記録に残っている失敗は10月7日から12日に集中していて、その期間に差し替えを受け取った端末だけが、値段の無い課金画面を見ていた。
審査で見つからないのは当然だった。審査で見られるのは、正しい鍵を持った方の版だからだ。
直したのは鍵1本と、検査1つ
鍵そのものは、設定ファイルの1行を経路アプリのものに直せば終わる。ただ、それだけだと次に作業場を増やしたときにまた起きる。
そこで差し替え配信の手順に、送る直前の検査を1つ足した。書き出した中身を文字として読み、3つのアプリの鍵がそれぞれ何回出てくるかを数える。経路アプリを送るなら、経路アプリの鍵が1件、ほかの2つのアプリの鍵が0件でなければ止まる。
直した版で実際に数えると、経路アプリの鍵が1件、タスク管理アプリと推し活アプリの鍵は0件だった。この結果を見てから送った。
正直に書いておくと、この記事を書いている時点では、直した配信を受け取った端末で実際に値段が表示されるところまでは、まだ自分の目で確かめていない。確かめたのは「送った中身に正しい鍵が入っていること」までだ。課金画面に値段が並ぶのは、その先で外部サービスが正しく答えてくれたときで、そこは端末で開いてみるまで分からない。
だから、この件の完了は次の朝のレポートで判断することにした。同じエラーが新しく出ている人が0人なら、届いた端末で直っている。数字で始まった件は、数字で閉じる。
3週間前、逆向きに同じことをしていた
ここまで書いて、似た失敗を思い出した。9月27日のことだ。
推し活アプリの作業場で、配信サービス側に登録する課金の鍵を更新する命令を打った。推し活アプリの鍵を、推し活アプリに入れるつもりだった。
ところが配信サービスのどのアプリに書くかは、作業場の場所では決まらない。命令を打つときに付ける「どのアプリか」という目印で決まり、目印を付け忘れるとタスク管理アプリが選ばれる。結果、タスク管理アプリの本番の鍵が、推し活アプリの鍵で上書きされた。命令は何の警告も出さずに成功した。
さらに悪いことに、直前に打った確認の命令もタスク管理アプリの値を読んでいた。それを推し活アプリの値だと思って読み、「推し活アプリにタスク管理アプリの鍵が入っている」と逆に誤解していた。
このときは、組み立てや差し替え配信をする前に気付いた。元の鍵に書き戻し、値が一致することを確かめたので、公開中のアプリには届いていない。もし気付かずに次の版を組み立てていたら、今度はタスク管理アプリで有料プランが買えなくなっていた。
2つの取り違えを並べると
| 9月27日 | 8月20日〜10月13日 | |
|---|---|---|
| 書いた場所 | 配信サービス側 | 手元の設定ファイル |
| 入った鍵 | 推し活アプリの鍵 | タスク管理アプリの鍵 |
| 入った先 | タスク管理アプリの本番 | 経路アプリの差し替え配信 |
| 気付いた時点 | 組み立て前 | 6人に届いた後 |
| 警告 | なし | なし |
向きは逆だが、根は同じだ。「いま自分がどのアプリの作業場にいるか」と「書き込みがどのアプリに届くか」が、別々の仕組みで決まっていた。作業場の中にいるという感覚は、書き込み先を何も保証していなかった。
名前ではなく、中身で確かめる
どちらの失敗でも、鍵の名前は正しかった。設定ファイルの項目名も、配信サービス側の項目名も、3つのアプリで同じ名前を使っている。同じ名前の箱が3つあって、中身だけが違う。名前を見て安心するかぎり、取り違えは見えない。
だから今は、鍵を扱う作業の前後で次の2つを必ずやる。
- 書く前に、書き込み先がどのアプリかを命令の出力で読む。作業場の場所では判断しない
- 送る前に、送る中身から鍵の実物を数える。項目名ではなく値で照合する
課金の鍵は、間違えても何も壊れたようには見えない。画面は開くし、エラーも利用者の手元で静かに出るだけだ。毎朝の集計で6人という数字が出なければ、まだ気付いていなかったと思う。
コメント (0)
まだコメントはありません。最初の一言を残しませんか?