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

Reply via email to