Gmailの「履歴を表示」実行時エラー
- 関連
- http://d.hatena.ne.jp/maoo/20100401/1270138697
- 関連
- http://d.hatena.ne.jp/maoo/20100404/1270401931
- 参考
- http://d.hatena.ne.jp/maoo/20100319/1269037138
(前書き)
そんなわけで、ありがたく多用させていただく日々がやってきた"Gmail"さんで*1あったりするのだが、どうもこれは内部のエラーというかバグというかそんなものじゃないかと思われる現象に遭遇したので、その件について書いてみる。これを正当な方法で報告することもできるだろうが、なんだか面倒そうだし回避できる手段があるのだからまあいいか…と。ああ、ごめんなさいごめんなさい。
現象の発生
"Mail Fetcher"という機能では、外部のe-mailアカウントからPOPによって*2メールを取得することが可能である。その稼働の状況については「履歴を表示」*3することができるのだが、その操作がうまく実行できない場合がある。具体的には
一時的なエラー (404) … 一時的に Gmail アカウントが利用できない状態になっています。大変申し訳ありませんが、数分後にもう一度試してください。 … 数値コード: 7
このようなerrorとなることがあるようだ。自分の環境においては、数時間を経過しても自動的な解決はしなかった。メールの取得自体は正常に機能しているので大きな問題ではないのだが、ちょっと気持ち悪い。
状況の観察
「履歴を表示」についてはWWWブラウザの別ウィンドウ(設定によってはタブ)に表示される仕様となっており、それぞれ独立したURLで*4アクセスする仕様となっているように思われる。(POP3)メールアカウントによってエラーとなる場合・ならない場合があったため、まずはそれらのURLを比較した。結果、リクエストパラメーター(の一部)において
ma_id=NaN
となっているような場合にエラーが発生するらしいと理解できた。もしも正常のケースであれば、'NaN'ではなく1以上の整数となるようだ。その部位を仮に(ア)と表現することにしよう。
一方、「履歴を表示」リンクに関する部分のHTMLソースを*5参照したところ、(ア)と一致する文字列が
<span id="
以降に指定される内容の4文字目から記述されているようだった。その部位を仮に(イ)と表現することにしよう。
興味深いのは、(イ)が十進数を*6表現した文字列になっていないと(ア)の内容が'NaN'となり、そして件のエラーが発生するらしいということだ。たとえば、(イ)が"7"であれば(ア)も"7"となり正常に処理されるし、(イ)が"9"であれば(ア)も"9"となり正常に処理されるが、(イ)が"e"であると(ア)は'NaN'となりエラーが発生した。ここでエラーとなったケースの(ア)つまり'NaN'を(イ)の内容に置換したURLにアクセスしてみると、正常な処理が行われることを確認できた。
原因の推測
'NaN'は*7数値ではないという意味だろうし、この場合は状況からして、クライアント側においてJavaScriptで*8なにか数値計算を行おうとした結果で発生している可能性が高いものと考えられる。すなわち、"id"を決定する処理ではその内容を十六進数で*9生成している一方で、そこから"ma_id"の内容を生成する処理では"id"の内容が十進数であるという前提があるのではないだろうか。その齟齬により、演算過程で'NaN'が発生しURLが不正となってしまう…と。
障害の回避
上記のようにURLを手作業で加工すれば正常な動作をさせることはできるが、いちいちそんなことをするのは面倒だ。ここはもう少し根本的に回避をする方法を発見したい。もちろん、もし自分が考えたとおりの障害であるのならば、開発元に連絡をして処理を修正していただくのが一番清く正しいのだが、清く正しくない自分は最初に書いたとおりそこから逃走しているわけだった。ああ、ごめんなさいごめんなさい。
まず、ここで(イ)に関して考えてみる。自分はテストやらなんやらで(POP3)メールアカウントを追加したり削除したりということを何度も何度も行っており、その過程で(イ)の値が
1,2,…,8,9,a,b,…,e,f,…
の規則に従うように大となっていったように思える。ただし、必ず1ずつの加算ということではなかったようだが。そして"a"〜"f"に該当するような領域に突入すると、おそらくは件の問題が発生するのだ。この推測が正しいのならば、この十六進数の領域から脱出することができれば(見かけ上で十進数と区別ができないようになるため)障害の回避ができるのではないだろうか?
そうなるとここで注目すべきは、上記"f"の後がどう続くかということだ。それにより、十六進数での表現になっているとの仮定が成立するかどうかが判明する。どうやらそれは間違っていなかったらしく、実際にためしてみた結果では
…,e,f,10,11,…
こうなるようだ。そして予想通り、(イ)が"10"以上になった時点で動作が正常になったことを確認した。蛇足ながら、桁が増えたことによって(イ)が1文字から2文字になってしまったのがほんのりと不安ではある。本件はいかにも「(イ)が0x0A(10)以上になることなんて想定していない」挙動っぽいし。もしシステムとしてこの付近の品質が低いとなると、新たなトラブルが発生しそうな予感がしないでもない局面だ。今のところきちんと動作しているようだが。
また、将来的に心配な点もあったりする。(イ)はおそらく
…,10,11,…,18,19,1a,1b,…,1e,1f,20,21,…
のように続いていくものであり、"1a"〜"1f"の領域に突入するとまた同じ障害が発生するのだろうと予想される。まあ、もうそんなに頻繁にはアカウントの追加・削除を行う予定もないし、同じことが発生したら同じように回避できるのだろうとは思うが。
さて、具体的な回避方法についてはわざわざ書くほどのことでもないと思うのだが、こうだ。すなわち「アカウントの追加と削除を繰り返して(イ)が十進数を示す文字列になるまで故意に値を増加させる」。全部のアカウントを削除そして追加するようなことをすると、かなり効率的なようだった。なんだかなあ…というような方法ではあるし、やっていてなんだか情けない気分にもなるが、結果としてこれでトラブルを回避できるのであればよいではないか。
(後書き)
ちなみに本件に関するこの文章については、当然のことながら、この日記を書いた本日の状況に依存しているものである。あなたがこれを読まれたのが未来のいつのことになっているのかは知らないが、その時にはGoogleさんの*10ところの優秀なエンジニア様がすでに問題を解決しているかもしれない。そうなっているといいな。そうなっていてほしい。よろしくお願いします、中の人。
(追伸)
ここまで長々と書いておいて今さらどうかとも思うが、本件がWWWブラウザ側の(あるいはそのアドオンなどの)環境なんて部分に起因していたり影響されたりしている可能性もちょっとはある気がする。そのあたりまで調査はしなかったのでわからないが。とりあえず自分の環境において回避ができてしまった時点で満足してしまったし。それでもさらに探求するようなことになるには、もっと元気が必要だよなあ、実際。
*2:参考 Post Office Protocol - Wikipedia
*3:「設定」→「アカウントとインポート」→「POP3 を使用したメッセージの確認:」
*4:参考 Uniform Resource Locator - Wikipedia
