api.php should honor maxlag
Closed, ResolvedPublic

Description

Author: cbm.wikipedia

Description:
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.


Version: 1.11.x
Severity: enhancement

bzimport added a project: MediaWiki-API.Via ConduitNov 21 2014, 9:51 PM
bzimport set Reference to bz11206.
bzimport created this task.Via LegacySep 6 2007, 2:56 AM
bzimport added a comment.Via ConduitSep 6 2007, 3:00 AM

lilewyn wrote:

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?

Catrope added a comment.Via ConduitSep 6 2007, 11:10 AM

Reassigning to Yuri, he's the API guy.

vvv added a comment.Via ConduitNov 18 2007, 9:42 AM

Fixed in r27598

Yurik added a comment.Via ConduitNov 18 2007, 5:40 PM

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, ...)

vvv added a comment.Via ConduitNov 18 2007, 6:55 PM

(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

bzimport added a comment.Via ConduitNov 18 2007, 7:09 PM

robert wrote:

(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.

Catrope added a comment.Via ConduitNov 18 2007, 7:39 PM

(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.

Yurik added a comment.Via ConduitNov 18 2007, 8:08 PM

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.

bzimport added a comment.Via ConduitNov 18 2007, 10:44 PM

cbm.wikipedia wrote:

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.

Yurik added a comment.Via ConduitNov 19 2007, 12:43 AM
  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.
vvv added a comment.Via ConduitNov 23 2007, 6:41 PM

Fixed in r27626, r27630.

Add Comment