Here are two threads related to this issue. http://groups.google.com/group/twitter-development-talk/browse_thread/thread/cd95ce07be341223/66c66de585383868#66c66de585383868 http://groups.google.com/group/twitter-development-talk/browse_thread/thread/3d6a727892710d5e#
It is an inconvenient change, not because they changed it, but because they did not announce that the change was happening. On Oct 21, 5:37 am, Dave Sherohman <d...@fishtwits.com> wrote: > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: > > Has anyone else noticed a change in the way that the 140 character > > limit is enforced via the API? I noticed a change sometime between the > > 13th and the 16th that is now causing all my 140+ character posts to > > be rejected by the API. > > Also a side note is that the api is not returning errors, they return > > proper responses however they are the proper response for the current > > status of the account, not the new status that was just attempted to > > be posted. > > My users first reported issues arising from this on the 15th, although I > didn't identify the cause until the 17th, at which point I asked about > it in #Net::Twitter and Marc Mims brought the question here under the > subject line "Bug? Updates > 140 characters return success with prior > update payload". See the discussion under that thread for more on it, > but the overall upshot is: > > - This is an intentional (if poorly-announced) change, not a bug. > - Status updates are known to be getting silently rejected in this > manner both due to exceeding 140 characters and due to violation of > the expanded "no duplicates" policy. > - Twitter has not stated whether there are any additional circumstances > beyond those two cases in which updates will be silently rejected. > - Twitter has not stated any plans regarding adding an indicator for > when a "200 OK" status update has, in fact, been rejected. > > I am attempting to compensate for this change by checking the returned > status ID against the previous highest-seen ID to determine whether the > status returned with the "200 OK" response is a new one or the user's > pre-existing status. This seems to work, but does not indicate the > reason for the silent failure, so I can't report the cause to my users. > Andy Freeman has mentioned that, in the case of rejection due to > duplication, this is also unsatisfactory in that it does not allow him > to identify the original status which was duplicated. > > -- > Dave Sherohman
