Last modified: 2007-11-23 18:41:34 UTC
It appears that api.php doesn't honor the maxlag parameter. If it doesn't, it should, especially since the edit code is being developed. Also, maxlag=0 should always cause the lag message to appear, so that it's possible to effectively test software frameworks to ensure they handle the lag message appropriately.
For API (which is still experimental afaik), you could get a "works so far" version by updating the parameter table and copy-pasting the code from index.php, ne? You'll want to make it a bit friendlier for bots, though. Are you going to write the patch for this?
Reassigning to Yuri, he's the API guy.
Fixed in r27598
If I understood correctly, the code will output a plain string in case of a lag error. This is not acceptable as API should always return results in the format requested (xml, json, ...)
(In reply to comment #4) > If I understood correctly, the code will output a plain string in case of a lag > error. This is not acceptable as API should always return results in the format > requested (xml, json, ...) > I don't think so. This format is already used in main part of the code, so it will be more simplier to make a common format for both main code and API
(In reply to comment #5) > (In reply to comment #4) > > If I understood correctly, the code will output a plain string in case of a lag > > error. This is not acceptable as API should always return results in the format > > requested (xml, json, ...) > > > > I don't think so. This format is already used in main part of the code, so it > will be more simplier to make a common format for both main code and API > It is much easier to parser <maxlag>Message</maxlag> than Message - considering the message could be changed depending on which wiki you are on.
(In reply to comment #5) > I don't think so. This format is already used in main part of the code, so it > will be more simplier to make a common format for both main code and API The main code and the API are very different: the main code is for browsers who expect a nicely-looking UI in HTML, the API is for programs who expect their output formatted as XML/JSON/whatever. In fact, both are completely different programs that just happen to support the same actions.
All API errors have a well defined format: <api> <error code="...." info="short description"> extended description (optional </error> </api> Non-XML format will obviously be different, but the structure will remain. The simplest way to achieve this is to call $this->dieUsage() from any module.
API calls can still generate squid errors that are not in the correct form for an API response. So programmers already have to handle the HTTP response code as part of normal error handling; doing it for maxlag is no harder than doing it for squid errors that are equally likely to happen when lag is high.
1) programmers have to handle many communication errors on many levels: DNS, TCP, HTTP, ... Squid is just one of them. These are not Application level errors - they report communication problems, and rarely can be handled by the client. 2) Everything we can properly report, from the app level, with proper error code and an informative description, we will. Lag is just one of them, and we could even return recommended time to wait before next attempt as an additional attribute of the error. Besides, there is a meta query that reports the same results - maybe we should just execute that query and include it's results when the lag time is too high. 3) Lag time is different depending on the API operation - meta queries sometimes do not even need db access, whereas page modification require high level of db interaction. Lag too high is a normal error, just like incorrect parameters, access restrictions, and many other causes.
Fixed in r27626, r27630.
