We have a database that we use to log receipts of all received messages. That database is having some issues, and our when application sees that, it decides to hand your clients back a 500 even though we've received the update. We're working to get that database stable so you once again see the expected behavior (a 200 response if everything went fine, a 401 response if you're not authorized, etc.). This is certainly annoying, but at the very least we're not losing your updates. Thanks for your patience.
> We have a database that we use to log receipts of all received
> messages. That database is having some issues, and our when
> application sees that, it decides to hand your clients back a 500 even
> though we've received the update. We're working to get that database
> stable so you once again see the expected behavior (a 200 response if
> everything went fine, a 401 response if you're not authorized, etc.).
> This is certainly annoying, but at the very least we're not losing
> your updates. Thanks for your patience.
> On Jul 2, 6:40 pm, "Alex Payne" <a...@twitter.com> wrote: >> We have a database that we use to log receipts of all received >> messages. That database is having some issues, and our when >> application sees that, it decides to hand your clients back a 500 even >> though we've received the update. We're working to get that database >> stable so you once again see the expected behavior (a 200 response if >> everything went fine, a 401 response if you're not authorized, etc.). >> This is certainly annoying, but at the very least we're not losing >> your updates. Thanks for your patience.
Thanks Alex. I really appreciate the transparency.
I do want to stress the importance of the return values however. The
post id is used in our products for several purposes:
a) published links back to twitter.
b) a marker to prevent circular posting.
c) as an endpoint for entity relationships based on analysis of the
status data.
From my perspective, I would prefer posts fail than succeed without
the return data.
cheers,
Jay
On Jul 2, 12:40 pm, "Alex Payne" <a...@twitter.com> wrote:
> We have a database that we use to log receipts of all received
> messages. That database is having some issues, and our when
> application sees that, it decides to hand your clients back a 500 even
> though we've received the update. We're working to get that database
> stable so you once again see the expected behavior (a 200 response if
> everything went fine, a 401 response if you're not authorized, etc.).
> This is certainly annoying, but at the very least we're not losing
> your updates. Thanks for your patience.