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@gmail.com wrote:
On Wed, Jul 15, 2009 at 5:30 PM, Roan Kattouwroan.kattouw@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api