For this issue, and all filtering-driven issues, they'll always be back-to-back. For other causes of overdelivery, duplicates can be scattered pretty far apart. Overdelivery is usually triggered by lifecycle events -- servers restarting, your client reconnecting, that sort of thing. This type of overdelivery is rare, but it can happen.
-John On Jun 10, 10:09 am, Chad Etzel <[email protected]> wrote: > Cool, thanks. > > I have noticed that the duplicates have always (thus far) come in > back-to-back, so I've just started checking the tweet id against the > last received tweet id to see if they match. Do you know if that > should always be the case (until the fix), or if I have just been > getting lucky so far? > > -Chad > > On Wed, Jun 10, 2009 at 1:04 PM, John Kalucki<[email protected]> wrote: > > > This is a known defect. Quick catch! The fix is easy enough and > > required for future features. > > > Streaming API clients need to de-duplicate for a whole host of other > > reasons, especially those who use the count parameter. The service > > errs on the side of overdelivery. > > > -John > > Service, Twitter Inc. > > > On Jun 9, 9:00 pm, Chad Etzel <[email protected]> wrote: > >> Makes sense. > > >> One thing I'm noticing that now this feature is live: > > >> If userA and userB are both in my follow id list, and then if userA > >> makes an explicit reply to userB, I get userA's update twice. Just > >> something to be aware of for everyone. > > >> This "duplicate update" also happens if you have the same user id > >> listed twice (or more) in the follow id list. I found this out by > >> merging two follow lists which overlapped. 'sort' and 'uniq' became > >> my friends soon thereafter. > > >> -Chad > > >> On Tue, Jun 9, 2009 at 11:24 PM, John Kalucki <[email protected]> wrote: > > >> > Unlikely. > > >> > In general, we treat a status as immutable, but removable. > >> > Hosebird doesn't re-write statuses. > >> > Clients can determine this by themselves. > >> > Too many other things to do! > > >> > -John > > >> > On Jun 9, 8:10 pm, Chad Etzel <[email protected]> wrote: > >> >> Neato! > > >> >> Would it be possible to add some sort of attribute to the status > >> >> object which indicates when this is the case? (i.e. this update is > >> >> being sent to you, but the user id of the sender is not explicitly in > >> >> the follow id list?) > > >> >> Would be handy, perhaps. > >> >> -Chad > > >> >> On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki <[email protected]> > >> >> wrote: > > >> >> > The follow by userID resources, /follow, /birddog and /shadow, stream > >> >> > all public statuses filtered by a list of userIDs. In addition to > >> >> > updates created by users in the list, explicit replies now also match > >> >> > and are streamed to consumers. > > >> >> > Mentions, statuses that contain a given screen name ("Hello @user!"), > >> >> > but aren't explicit replies, are not matched. > > >> >> > -John Kalucki > >> >> > Services, Twitter Inc.
