Not very good.
Now we have to mung two different layers of code together, to treat
what should be API status but is being thrown as a network transport
error. IMHO a poor design choice.
For example in my code, using Python urllib, it will disable the
maxlag - backoff, seeing network transients and retrying very
aggressively. To fix it, I have to add code at transport to catch the
exception, turn it back into a "normal" API response, and return it.
(I certainly can do this, but what I'm doing is patching over what is
basically a bad response.)
best regards
Robert
On Thu, Jul 16, 2009 at 2:39 AM, Carl (CBM)<cbm.wikipedia(a)gmail.com> wrote:
On Wed, Jul 15, 2009 at 5:30 PM, Roan
Kattouw<roan.kattouw(a)gmail.com> wrote:
As of r52190 [1], API maxlag errors (the kind of
error you get when
you set &maxlag=2 and the maximum slave lag is higher than two
seconds) return a HTTP 503 status code rather than a 200, for
consistency with index.php (which does the same thing). The text of
the response has not changed:
<api>
<error code="maxlag" info="Waiting for 10.0.6.38: 1 seconds
lagged" />
</api>
If this is a 503 error, can't we set an HTTP header with the retry
delay? Otherwise this adds yet another complexity to error handling.
Index.php sets "Retry-After" and "X-Database-Lag" headers when
maxlag
is exceeded, via wfMaxlagError().
- Carl
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api