We're always working to improve our duplicate tweet detection
routines, and as such there's no hard equation you can follow for
issuing duplicate tweets reliably. I'm a big advocate for expressing
these kind of limits in a way you can interpret programatically but in
this case the target is moving. By indicating the time window when a
duplicate of the recently submitted tweet could be resubmitted, we
would be opening an abuse vector.

Including something unique in the string might be your best bet to get
around this.

On May 22, 11:19 pm, Mr Blog <mrblogdot...@gmail.com> wrote:
> My GaragebBot tweets when doors are opened or 
> closed:http://twitter.com/connectedthings
> The tweets are of the form:
> tweet 1: Door 2 opened
> tweet 2: Door 2 closed manually
> tweet 3: Door 1 opened
> tweet 4: Door 2 opened
> tweet 5: Door 2 closed automatically
> tweet 6: Door 1 closed manually
> The behavior up until a few days ago was duplicates were defined as
> tweet N+1 being identical to the prior tweet N, but now there appears
> to be some kind of cache where "tweet 4" above fails with a "403
> duplicate tweet" error even though it is not a duplicate of the most
> recent tweet (but is the same message as tweet 1, but a different in
> time, so thus meaningful).
> In this case, the garage only tweets about 6 different messages and it
> has been doing so for several years, with great success, but now
> almost all tweets are being rejected as duplicates.
> I could change it to put some random garbage at the end of each new
> tweet, but that doesn't seem very elegant.

Reply via email to