On Sun, Oct 18, 2009 at 04:48:13PM -0700, Naveen wrote: > I agree. A silent failure seems like the wrong behavior.. It should > return an error if the tweet has failed to post.
It's actually relatively benign in this specific case, since you can chop the status text down to 140 characters before submitting it, thus ensuring that it won't be rejected for length. However, Twitter has also gotten a bit more strict with blocking duplicate statuses. While testing my fix for the "silently reject over- length status text" problem, I was getting a lot of failures when I knew I was sending updates that were under 140 in length. It turned out that any update which was a duplicate of another update sent within the last hour (if not longer) was also being silently rejected in the same manner, even if it was not the same as the user's most recent status. This is not a failure mode which can be reliably anticipated or compensated for prior to submitting the update, therefore Twitter *must* provide some indication in the response that it was rejected. There may also be other circumstances in which an update will silently fail which I haven't yet discovered. My current attempt at working around this is to compare the returned status ID against the highest ID previously seen by my application and, if the returned ID is not greater than the previous highest, reporting that the update was "rejected for an unspecified reason". I don't like being unable to tell my users why it failed, but that seems to be the most reliable way of detecting these silent update failures until/ unless Twitter provides notification that the update was rejected and at least a hint as to why. > Also this change was made without any announcement that I recall > seeing or can find now. This is a pretty significant change in > behavior for existing clients.. We are failing to post because people > are not getting an error and they believe it is our problem. Agreed. That is a definite problem. -- Dave Sherohman