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)<[email protected]> wrote: > On Wed, Jul 15, 2009 at 5:30 PM, Roan Kattouw<[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/mediawiki-api > _______________________________________________ Mediawiki-api mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
