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.
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
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
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,
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 jazzyc...@gmail.com wrote:
Neato!
Would it be possible to add some sort of
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
