Message from discussion
Regarding the 500 errors on /statuses/update
Received: by 10.114.193.1 with SMTP id q1mr4708888waf.12.1215016857317;
Wed, 02 Jul 2008 09:40:57 -0700 (PDT)
Return-Path: <a...@twitter.com>
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.243])
by mx.google.com with ESMTP id k36si2856428waf.0.2008.07.02.09.40.57;
Wed, 02 Jul 2008 09:40:57 -0700 (PDT)
Received-SPF: pass (google.com: domain of a...@twitter.com designates 209.85.198.243 as permitted sender) client-ip=209.85.198.243;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of a...@twitter.com designates 209.85.198.243 as permitted sender) smtp.mail=a...@twitter.com
Received: by rv-out-0708.google.com with SMTP id f25so458107rvb.54
for <twitter-development-talk@googlegroups.com>; Wed, 02 Jul 2008 09:40:57 -0700 (PDT)
Received: by 10.140.127.13 with SMTP id z13mr4492742rvc.142.1215016857013;
Wed, 02 Jul 2008 09:40:57 -0700 (PDT)
Received: by 10.141.163.17 with HTTP; Wed, 2 Jul 2008 09:40:56 -0700 (PDT)
Message-ID: <ca1278640807020940l10e82ea7s35dea66f41435b96@mail.gmail.com>
Date: Wed, 2 Jul 2008 09:40:56 -0700
From: "Alex Payne" <a...@twitter.com>
To: twitter-development-talk@googlegroups.com
Subject: Regarding the 500 errors on /statuses/update
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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.
--
Alex Payne
http://twitter.com/al3x
|
