[twitter-dev] Re: Twitter API allowing multiple Posters
Don't need any app. Everyone can log into the same account at the same time. Is that the issue?
[twitter-dev] Re: "about 8 hours ago from API"
http://twitter.com/statuses/update.format?source=appname
[twitter-dev] Re: Platform Status Update, Tuesday 2:00pm PST
Oops. spoke too soon. Still eradic problems - same symptoms. Incorrect rate_limit response on statuses/followers when ..ids calls work perfectly on the same account.
[twitter-dev] Re: Platform Status Update, Tuesday 2:00pm PST
We reported/documented inconsistent, incorrect responses on statuses/ followers, statuses/friends. After a few reboots, to correct connections that have been left open, all the accounts are working. We'll be monitoring for any additional problems. Thanks for the fast response - after our report today. Hopefully, the problems have been resolved for other developers as well.
[twitter-dev] Re: Platform Status Update, Monday 4:30pm PST
Here's the typical errors. Call 1 says 132 hits remaining; call 2 returns over the limit. Once an hour, call 2 slips through and returns the right result. Otherwise, on some accounts - the rate_limit bug blocks access. On other accounts, there is no problem at all. Sometimes, the problem resolves on one account; and moves to another. In my humble opinion, the bugs trace to out-of-control, unpredictable rate-limiting statements. Also, note reset time in seconds makes no sense. 1. http://twitter.com/account/rate_limit_status.xml Results: 132 150 2009-08-18T17:32:14+00:00 1250616734 2. http://twitter.com/statuses/followers/scotmckay.xml Results: /statuses/followers/scotmckay.xml - Rate limit exceeded. Clients may not make more than 150 requests per hour.
[twitter-dev] Re: Platform Status Update, Monday 4:30pm PST
Our IP: 69.107.71.66 Your IP: 168.143.162.68 Via AT&T Dynamic DSL We host Twitter accounts for enterprise clients - each via basic authentication 24x7 via FF3.5. No memory leak observed on FF3.5 - despite the problems. We're staring at dozens of identical Vista machines - some work happily, others fail. After the Sat reset and Mon corrections, here's what we're seeing: Reliable performance: (e.g. 99%+ correct) - search - statuses/update - POST - statuses/user_timeline - account/rate_limit_status - ..ids - friendships/create - POST Unreliable with frequent fails: - statuses/followers (e.g. 10% correct. Every few hours, one request responds correctly ;-) - statuses/friends (e.g. 80% correct) On problem accounts, cookies have been deleted without helping. On error, returns XML rate limit error. JSON calls get no-server msg. Other api calls/results & rate_limit_status calls contradict the returned error messages. Hope that helps.
[twitter-dev] API fails - statuses followers
After the Saturday reset, here's what we're seeing: Reliable performance: - search - statuses/update - statuses/user_timeline - account/rate_limit_status - ..ids - friendships/create Unreliable with frequent fails: - statuses/followers - statuses/friends Returns rate limit error, despite other api results contradicting the error message. Hope that helps.
[twitter-dev] Re: API Changes for August 12, 2009
Every change detail is helpful. On Aug 13, 12:21 pm, Alex Payne wrote: > A day late and a bug short... > > - FIXED: /account/verify_credentials no longer enforces a rate limit > that's inconsistent with the rest of the API. > > Thanks. > > -- > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] ids fails most frequently
During the DDOS attack, the Twitter ids fails the most - returning nothing. Statuses, friends, and followers calls can also fail, returning random/ incorrect error messages; but less frequently. Update calls seem to be ok. FYI