[twitter-dev] Re: since_id too recent, poll less frequently
Dittoing Cameron here, Twitterfall isn't seeing it any more, though it was practically disabling us last night and I was getting concerned, because I slowed things down greatly but to no avail, and I thought I'd missed some update about it. The HTTP status code was 403 IIRC. Another +1 for wondering what triggers the error. -David On Apr 16, 4:02 am, Chad Etzel jazzyc...@gmail.com wrote: Ditto. It seemed completely random to me. I know I was way under the search rate-limit. I haven't seen it lately either. +1 for wondering what exactly throws this error? -Chad On Wed, Apr 15, 2009 at 9:59 PM, Cameron Kaiser spec...@floodgap.com wrote: Cameron, Chad, and the Tweetfall duo pinged me this afternoon to let me know there is a new error cropping up from the search API. The error text is since_id too recent, poll less frequently. What HTTP status code is associated with this error? Any hint for how long to wait before retries? Or is that dynamic? The problem is that I'm not seeing it anymore, and I never got a good handle on what exactly caused it to trip. For example, you would think thrashing it with reloads would hit it every time, and it wasn't. I got reports from TTYtter users about it under intermittent circumstances and then suddenly they evapourated. But if there's a simple condition I can use to determine when not to send a query, I'll gladly add it (i.e., what is 'too recent'). -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- Put your Nose to the Grindstone! -- Plastic Surgeons-Toolmakers Union Ltd. -
[twitter-dev] Re: since_id too recent, poll less frequently
I think it was the 'poll less frequently' that was throwing us all off. Glad to hear it was just a sanity check going...insane. -David On Apr 16, 4:01 pm, Matt Sanford m...@twitter.com wrote: Hi everyone, This error check has always existed in the search code, but most people never see it. This is a sanity check on the since_id parameter to prevent people using ones in the future. The problem yesterday was specifically that several back-ends fell behind. If you hit an up-to- date back-end and collected a max_id, then hit an out-of-date back-end it would complain that you were using a since_id in the future from its perspective. We've corrected most of the back-ends but we have a few more upgrades this evening to fix the last few. Sorry for the delayed reply but I need to focus on fixing and not email. Thanks; — Matt Sanford / @mzsanford On Apr 16, 2009, at 03:01 AM, @Jalada wrote: Dittoing Cameron here, Twitterfall isn't seeing it any more, though it was practically disabling us last night and I was getting concerned, because I slowed things down greatly but to no avail, and I thought I'd missed some update about it. The HTTP status code was 403 IIRC. Another +1 for wondering what triggers the error. -David On Apr 16, 4:02 am, Chad Etzel jazzyc...@gmail.com wrote: Ditto. It seemed completely random to me. I know I was way under the search rate-limit. I haven't seen it lately either. +1 for wondering what exactly throws this error? -Chad On Wed, Apr 15, 2009 at 9:59 PM, Cameron Kaiser spec...@floodgap.com wrote: Cameron, Chad, and the Tweetfall duo pinged me this afternoon to let me know there is a new error cropping up from the search API. The error text is since_id too recent, poll less frequently. What HTTP status code is associated with this error? Any hint for how long to wait before retries? Or is that dynamic? The problem is that I'm not seeing it anymore, and I never got a good handle on what exactly caused it to trip. For example, you would think thrashing it with reloads would hit it every time, and it wasn't. I got reports from TTYtter users about it under intermittent circumstances and then suddenly they evapourated. But if there's a simple condition I can use to determine when not to send a query, I'll gladly add it (i.e., what is 'too recent'). -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- Put your Nose to the Grindstone! -- Plastic Surgeons-Toolmakers Union Ltd. -
[twitter-dev] Re: Streaming API: missing updates non-indexed user correlation?
I'd like to also voice my agreement with Chad here, if you're specifically wanting to follow someone/thing you should get it. I agree with filtering in search, but in this case you are purposefully stating you wish to follow someones updates, and the result should reflect that, regardless of how much they spam. -David Twitterfall.com On Jun 5, 6:58 pm, Chad Etzel jazzyc...@gmail.com wrote: Ok, at least that confirms my suspicions about why those updates were not being delivered. If I may make an argument to separate the policy between Search and Hosebird (at least for the /follow methods)... In the case of the /follow methods (as opposed to the unfiltered /(fire|garden)hose methods), there is specific intent to get the updates of a particular user. Even if Twitter considers a user unworthy of indexing in Search (for whatever reason), I purposefully want to receive their updates and am stating as much by putting their userid in the follow parameter. In other words, I am opting-in to get those updates whether Twitter considers them spammy or not. If a user account is not in an officially suspended state, I think they should be fair game for /follow methods. Any other opinions out there? -Chad On Fri, Jun 5, 2009 at 1:44 PM, John Kalucki jkalu...@gmail.com wrote: There are multiple bits set for accounts that control various levels of access and all kinds of folderol. It's complicated and for mostly understandable reasons, purposefully opaque. Search and Hosebird currently have identical access rules, but that's subject to change. In this case, it appears that everything is working by the rules, if not also by design. These two concepts are not always in alignment! -John Kalucki Services, Twitter, Inc. On Jun 5, 10:09 am, Chad Etzel jazzyc...@gmail.com wrote: Hi John, et al. I have been playing with the /follow streams and noticed that some users' updates don't appear at all. This was really confounding for quite a while. Then I noticed that using the search API to search for from:user returned no recent results. An example is @KimSherrell. I have been trying to get her updates in the /follow stream (she posts *a lot*) as a way to verify that it is working. Lo and behold her most recent entry in the Search API is from 5 days ago:http://search.twitter.com/search?q=from:kimsherrell I know there is some administrative bit on the accounts that determines whether a user will be indexed by Search; is this same bit used to determine whether their updates will go out on the Hosebird streams? If so, may I ask why? Thanks! -Chad
[twitter-dev] Re: via, RT, and reply_to linking
Sounds like a bad idea simply because the name of it IS 'in_REPLY_to_status_id', and retweets aren't replies. I wonder if Twitter will adopt retweets in any way, in the same way they did with replies? On Jun 22, 7:08 pm, Chad Etzel jazzyc...@gmail.com wrote: For the moment, I'll skip my rant about how stupid I think the via mechanism is, but I'm starting to notice a trend that several clients are now starting to set the in_reply_to_status_id data when the tweet is in fact a retweet/repost. I'm not sure how I feel about this. One the one hand, they aren't replies, so it just seems like noise. One the other hand, it does give a direct link to the original source. How do others feel about this? -Chad
[twitter-dev] Re: Tweet threading
We do the same at Twitterfall - recursive calls from parent to parent until there is no more. Check out http://twitterfall.com (find something that is a proper reply first). An icon appears between the two user names when it thinks there is a conversation. Sometimes it fails because it is doing a check for tweets starting with '@someone' too (because IIRC search results do not return the tweet ID the tweet is replying to) for popular trends, as our backend sends out limited tweet data. David Lead Developer Twitterfall.com On Jul 2, 12:11 am, Scott Haneda talkli...@newgeo.com wrote: Hope this is not out of line, but this list has been pretty busy lately in traffic, and I am looking for a little hand holding on tweet threading... so bump :) On Jun 30, 2009, at 3:53 PM, Scott Haneda wrote: I am finding near all apps I use with twitter in some way or another fail at threading a conversation. Anyone have pointers for how to do this, based on the current twitter API, and whatever bugs have been uncovered, perhaps with workarounds? Each tweet has a 'in_reply_to_status_id', if I understand, the existence of in_reply_to_status_id, means that the current tweet is a child of some parent. tweet: id = 1234 in_reply_to_status_id = 5678 In the above example, tweet #5678 would be the start of the conversation, and tweet #1234 would be the reply? What has me stumped: http://twitter.com/criticalmassey/status/2383870573 Clearly a reply to something @ahem said, which started here: http://twitter.com/Ahem/status/2382725245 However, if I search.twitter.com for @ahem, I can get this conversation: http://dl.getdropbox.com/u/340087/Drops/06.30.09/twitter-b06e01bd-154... But it is missing the parent, the start of the thread. I can see the master parent here: http://search.twitter.com/search?max_id=2410761989page=2q=+from%3Aa... But threading is not an option. Having a hard time wrapping my head around what the limitations of threading are. Any suggestions on how to better understand this would be most appreciated. Ideally, what I am looking for, is to take any tweet, determine what other replies there are to it, and get back to the parent, displaying all children. I would like to avoid any ambiguous tweet searches that are not based on a message-id, and could pollute the results with inaccurate threading. -- Scott * If you contact me off list replace talklists@ with scott@ *
