Dave, thanks a bunch. You called it. Looks like the update was greater than 140 characters and the API was failing silently.
Thanks! Enlai 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 > YMMV. > >
