Bug? Updates > 140 characters return success with prior update payload
Marc Mims
according to the documentation. Instead, the update call returns with
a 200 status and the payload contains the prior update.
Has there been a change to the API or is this a bug.
Josh Roesslein
The docs should be updated soon.
Dave Sherohman
> > Updates longer than 140 characters should be forcibly truncated
> > according to the documentation. Instead, the update call returns with
> > a 200 status and the payload contains the prior update.
> >
> > Has there been a change to the API or is this a bug.
> This is a change in the API confirmed by one of twitter's API members.
> The docs should be updated soon.
indicate when this has happened, or if the update has been rejected for
any other reason? Failing silently does not seem appropriate,
particularly when the failure returns the user's previous status.
--
Dave Sherohman
Naveen
return an error if the tweet has failed to post.
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.
Because the failure is silent we do not notify the user of the
problem. We will update our code with a work around, but I would have
expected some sort of announcement that this was going to happen.
On Oct 17, 6:23 pm, Dave Sherohman <d...@fishtwits.com> wrote:
> > On Sat, Oct 17, 2009 at 10:41 AM, Marc Mims <marc.m...@gmail.com> wrote:
> > > Updates longer than140characters should be forcibly truncated
> > > a 200 status and the payload contains the prior update.
>
>
Dave Sherohman
> 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
Andy Freeman
it's a dup of, not just the last status.