[twitter-dev] API Bug: Malformed JSON returned for some requests
*Full bug report is here: https://gist.github.com/1064338* Summary: The Twitter API returns malformed JSON for some valid requests. I discovered this while attempting to fetch all of my list memberships via the API. The issue is present regardless of authentication. It occurs 100% of the time, and has persisted for over twelve hours. I have reproduced it for multiple users. Note that the response does not indicate any error condition. The transaction completes successfully, but the payload is malformed. It seems that any user with enough lists will eventually have a page returned containing this bug. I've located it on the first two users I tried, which is my own account (@idangazit ~120 listed) and that of Jacob Kaplan-Moss (@jacobian, ~500 listed), founder of the Django web framework. The offending queries: These are two examples: http://api.twitter.com/1/idangazit/lists/memberships.json?cursor=1336796671888485791 http://api.twitter.com/1/jacobian/lists/memberships.json?cursor=1343747472518328819 Note that these are literally the first two users I inspected. I imagine this bug affects anybody with a sufficient number of lists. I have not encountered the issue in any other API call, but I haven't looked very hard, either. All of the following applies to my account, but is equally reproducible for @jacobian, albeit with different values. Starting with cursor=-1, the following (stable) progression of next_cursor values lead to the broken query result: - 2nd: 1370876429079454131 - 3rd: 1363944001883709517 - 4th: 1352913498669071334 - 5th: 1336796671888485791 Each of the requests leading up to the offender return well-formed JSON. The problem is a superfluous empty value at the very end of the lists value, more easily seen on line 956 of the pretty-printed JSON attached to this gist. Pasting the JSON into a validity checker like http://jsonlint.com handily points out the invalid serialization. Interestingly, the developer console in Twitter for Mac munges the response to replace the trailing comma with null, thereby making it valid JSON (screenshot:http://cl.ly/1q072g380B0P3g213t3e). Regardless, the bytestream from the server contains invalid JSON. Raw and pretty-printed dumps of the transaction are available in the gist linked at the top of this post. Thanks! Idan (@idangazit) -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] lists/memberships and authentication
Hey All, The docs for :user/lists/memberships indicates that auth is required, and yet this method works without authentication. Is this just a bug in the docs? The same information *is* available for unauthenticated browsers on the twitter website. To be clear, I want to use this unauthenticated, just want to make sure that I can rely on the behavior. -I -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] users.show follower count vs followers/ids count
Hi Folks, I've run into an interesting question that's not really addressed by the docs. Background = In the documentation for followers/ids, it states: (Please note that the result set isn't guaranteed to be 5000 every time as suspended users will be filtered out.) In addition, it seems that http://bit.ly/lp2f6 (thread in this forum) claims that some zero-length pages may be interspersed among the pages containing ID's The Question === I've carefully retrieved every page of followers/ids for a user with roughly 20K followers, stopping only after three consecutive zero length pages. The total number of id's fetched is about 25% lower than the count reported by users.show(). Can I surmise that the delta between the two follower counts is due to suspended accounts? Is there a twitter api bug in play? Or a combination of both? Alternatively, an explanation of why the followers/ids total count differs from that of users/show would be terribly interesting. Thanks! -Idan
[twitter-dev] Re: users.show follower count vs followers/ids count
Hey Chris, Not that I doubt you (I saw your earlier thread on the subject) -- I just want to hear it from the mouths of the twitter devs themselves. Hey devs, throw us a bone! :) -I On Jul 7, 3:41 pm, Chris Prakoso brajamu...@gmail.com wrote: So far, according to my test, that is the case. i.e. the delta is the number of suspended accounts. HTH, Chris On Tue, Jul 7, 2009 at 12:18 PM, Idan Gazit i...@pixane.com wrote: Hi Folks, I've run into an interesting question that's not really addressed by the docs. Background = In the documentation for followers/ids, it states: (Please note that the result set isn't guaranteed to be 5000 every time as suspended users will be filtered out.) In addition, it seems that http://bit.ly/lp2f6 (thread in this forum) claims that some zero-length pages may be interspersed among the pages containing ID's The Question === I've carefully retrieved every page of followers/ids for a user with roughly 20K followers, stopping only after three consecutive zero length pages. The total number of id's fetched is about 25% lower than the count reported by users.show(). Can I surmise that the delta between the two follower counts is due to suspended accounts? Is there a twitter api bug in play? Or a combination of both? Alternatively, an explanation of why the followers/ids total count differs from that of users/show would be terribly interesting. Thanks! -Idan
