Intermittent 404 responses from REST API

[remagio]

Since CET morning it works fine also without any DNS trick. We are monitoring and catching any 404 since the beginning but I hope Twitter keep us informed about when their intermittent 404 is solved.
We related our fixes to this Twitter issue,
Cheers
Renato

[Intrepidd]

We’re still seeing lots of errors

[remagio]

Probably is now in some way “zone dependent” within official Twitter balancers. Or only lucky.
Btw our servers located in NY1&NY2 plus EU1 didn’t get any 404 since this morning (CET tmz). Where usually we got since the beginning at any time.

[benorama]

Indeed, we don’t get any 404s since this morning, but we’ve got plenty of 500s instead (much more than 404s).

500:Something is broken. Please post to the group (https://dev.twitter.com/docs/support) so the Twitter team can investigate.
message - Internal error
code - 131

Here is the increase in number of exceptions by our error tracking system:

And nothing official on Twitter status page https://dev.twitter.com/overview/status.

Don’t you get thousands of 500s instead of 404s?

[Gazou_medialab2]

Here in France, still getting (a bit less) 404s, haven’t seen any 500.
Did not try and use a dedicated host, I’d rather know it’s happening than hide it and break another day.

[benorama]

So 404s are back since friday…
Nothing much has changed, still the same problem.
Anyone tried the DNS trick by @jamiel ?

[benjaminnimmo]

Same here plenty of 404’s. Not consistent to accounts or endpoints.

[edsu]

Interesting, so the problem seems to be geographically dispersed?

[mftb]

i’m seeing this often both on my personal machine and on my server-based robots. both when posting tweets and polling a mentions timeline. thankfully, the polling is only there as a backup to the streaming client, which works fine, but the errors when posting stuff are a problem when you can’t easily decide whether retrying is a good idea.

[QVSource]

We are also seeing intermittent 404 errors for the user_timeline endpoint.

[vaolaritei]

I have the same issue since August 7th and sometimes affects around 80% of the calls which makes unable to use the API from our application. It is someone working on this problem? How can we track a progress on this?

BR,
Valentin

[vaolaritei]

I tried the hack in the etc/hosts but was still getting 404 errors. Can be this a wrong error code returned by the API?

[FletchMarc]

We are seeing this issue as well. Any response from the twitter tech team?

[benorama]

It looks like the problem has been solved since Aug 14th. Cool !

[Intrepidd]

We’re seeing this as well.

Glad it’s finally sorted out but it’s a shame the twitter team didn’t acknowledge the issue.

[vaolaritei]

I still have this issue, but not so often as used to be. IMO i think that the bug is still there

[Gazou_medialab2]

Problem solved here as well since the 14th.
Will we ever know whether Twitter’s devteam actually did something or if the guilty machine was eventually removed without even noticing the users complaints?

[andypiper]

Dropping in here to say that we’ve certainly been aware of comments along these lines.

Unfortunately it is very difficult for us to answer every thread on the forums, or to debug issues that we aren’t able to reproduce ourselves. The forums are primarily intended for peer-to-peer API discussions and direct announcements, although some of us try to be as responsive as we can to the different categories here. We’re not able to be here 24x7.

Personal speculation - there’s a chance that some backend optimisations may have helped; that a Mesos host may have changed and cached / invalid paths were being hit; or that something outside of Twitter’s network could have affected this.

Glad to read that some folks are seeing better performance, but as with many large-scale web systems, unfortunately there’s a chance of occasional 404s along some of the API paths.

[Gazou_medialab2]

Thanks for the reply @andypiper

Although, as the graphs showed above, it was not “an occasional 404 along some of the API paths”, I personally saw more than 5000 of them in one month over 6 different routes (all the REST ones I use).

Reproducing it only required to run a few queries per minute during 15 minutes and you could be sure it would happen.

Just having an early answer from the team aknowledging the issue and at least saying “sorry we do not know where it comes from, please hang in there and handle those 404 until then” would have been way nicer, instead of letting us figure out on our own through deductions whether it was indeed coming from Twitter’s side and not ours.

[andypiper]

Appreciate that feedback (and I am not trying to say that there was no issue / that it didn’t have an impact). We take that on-board, and will endeavour to be more responsive!

Thanks for your patience and support