Dave, thanks a bunch. You called it. Looks like the update was greater 
than 140 characters and the API was failing silently.



Dave Sherohman wrote:
> On Mon, Nov 02, 2009 at 09:38:48PM -0800, Enlai wrote:
>> Sorry if this is a dumb question but I can't find an answer online.
>> This is happening right now so I thought I'd see if something is up
>> with the API.
>> Sometimes, I get no response from the status update post and other
>> times, I get a response with a successful post result. However, the
>> text in the post shows the previous successful post rather than the
>> one I just posted.
>> What does this mean? Has some rate been tripped?
> This has been noted by a few of us since mid-October.  Twitter changed
> the API behaviour such that a status update will fail silently and
> return the user's most recent prior status in two (known) cases:
> - If the text of the update exceeds 140 characters.  (This is a change
>   from the documented behaviour of truncating the text to 140
>   characters.)
> - If the text of the update is a duplicate of *any* previous status
>   update within an as-yet-unknown time period.  I know from my own
>   experience that the time period is at least an hour and I suspect that
>   it it much longer, perhaps even unlimited.  (This is a change from the
>   documented behaviour of only rejecting duplicates when consecutive.)
> There has been a comment made here on the list to the effect that
> Twitter intends to respond with an error code in these cases rather than
> failing silently, but no indication was given regarding an expected
> timeframe.
> Until Twitter does get around to telling us when updates have been
> rejected, two basic approaches have been suggested for detecting these
> silent failures:
> - Store the highest status ID which has been seen by your application.
>   When you submit an update, check the ID of the returned status.  If
>   the returned ID is less than the stored ID, you know the update was
>   rejected and an old status was returned.
> - Compare the text of the sent status to the text of the returned status
>   to see if they match.
> I prefer the ID-based method, as the text-based method is subject to
> both false positives (if Twitter applies bit.ly shortening, you'll think
> it failed unless you remember to ignore URLs when comparing the text)
> and false negatives (if the update is a duplicate of the user's most-
> recent status, the text will match even though the update failed), but

Reply via email to