M.C.P.C.

―むり・くり―プラスコミュニケーション(更新終了)


| トップページ |

2012年6月23日 17:39

Twitter不具合時にエラーメッセージを狩るモノたち

このエントリーをはてなブックマークに追加 mixiチェック

そういえばおととい、久しぶりにTwitterの盛大なサービス不能が発生していましたが。

ニュース - Twitterに障害発生、原因はインフラコンポーネントの連鎖的バグ:ITpro [itpro.nikkeibp.co.jp]

僕は今一般的には無職と呼ばれているのですが蔭ではTwitter botなどを作っているものですから、そのTwitterが落ちている時、APIからどういうエラーメッセージが返ってくるかというのを収集しようと思いながらTwitterに投稿投げ続けてそして寝落ちした。

その時採集できたのは、

  • ①Can't connect to http://api.twitter.com:443
  • ②Can't connect to http://api.twitter.com:443 (接続を拒否されました)
  • ③Can't connect to http://api.twitter.com:443 (接続がタイムアウトしました)
  • ④Status read failed: 接続が相手からリセットされました

とかなんとか。④が今まで採集できていなかった。

こんなの採集してどうするかっていうのだけれども、botの発言って、API投げっぱなしで通ったかどうか確認しなくてもいいタイプのものと、API通ったか確認しないと次の発言投げられないタイプのものがあるわけです。

で、僕の作っているbotは、エラーメッセージの内容によって、発言をもう一度し直さなければならないのです。

実は、発言が通っているけどエラーが返ってきて、リトライとして2回目に同じ発言すると重複投稿となり、別のエラーが返ってくる、という場合もあります(Bad gateway→Forbiddenのコンボ)。そこのエラー処理をしないと永遠に同じ発言することになるので、ステート記録してシーケンスを工夫したり、未知のエラーの場合はリトライ回数を決めておくとかするとか、そーいう細かい気配りが必要になってくるのです。

というわけで、久々のTwitter不具合でbotのエラー対応力がよくなったりならなかったりするというお話でした。これは金にならない。道理で無職だ。

投稿 大野 義貴 [パソコン・インターネット] | |

トラックバック(0)

トラックバックURL: http://blog.dtpwiki.jp/MTOS/mt-tb.cgi/3993

コメントする