TwitterBridge: discard outgoing queue items instead of retrying when Twitter API returns HTTP 400 or 404 error codes

We get HTTP 400 for various cases of invalid data, where retrying doesn't help at all -- previously those would loop forever, or until something died at least. :)
400 is also used for rate limiting, but retrying *immediately* will just hit the rate limit again, so better to discard if we're going over for now.
This commit is contained in:
Brion Vibber 2011-03-24 18:41:25 -07:00
parent 22bf63bb46
commit d994b4583a

View File

@ -320,7 +320,20 @@ function process_error($e, $flink, $notice)
common_log(LOG_WARNING, $logmsg); common_log(LOG_WARNING, $logmsg);
// http://dev.twitter.com/pages/responses_errors
switch($code) { switch($code) {
case 400:
// Probably invalid data (bad Unicode chars or coords) that
// cannot be resolved by just sending again.
//
// It could also be rate limiting, but retrying immediately
// won't help much with that, so we'll discard for now.
// If a facility for retrying things later comes up in future,
// we can detect the rate-limiting headers and use that.
//
// Discard the message permanently.
return true;
break;
case 401: case 401:
// Probably a revoked or otherwise bad access token - nuke! // Probably a revoked or otherwise bad access token - nuke!
remove_twitter_link($flink); remove_twitter_link($flink);
@ -330,6 +343,13 @@ function process_error($e, $flink, $notice)
// User has exceeder her rate limit -- toss the notice // User has exceeder her rate limit -- toss the notice
return true; return true;
break; break;
case 404:
// Resource not found. Shouldn't happen much on posting,
// but just in case!
//
// Consider it a matter for tossing the notice.
return true;
break;
default: default:
// For every other case, it's probably some flakiness so try // For every other case, it's probably some flakiness so try