Last modified: 2007-11-23 18:41:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11206 - api.php should honor maxlag
api.php should honor maxlag
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.11.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Yuri Astrakhan
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-06 02:56 UTC by CBM
Modified: 2007-11-23 18:41 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description CBM 2007-09-06 02:56:29 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.
Comment 1 Nobody 2007-09-06 03:00:01 UTC
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?
Comment 2 Roan Kattouw 2007-09-06 11:10:39 UTC
Reassigning to Yuri, he's the API guy.
Comment 3 Victor Vasiliev 2007-11-18 09:42:45 UTC
Fixed in r27598
Comment 4 Yuri Astrakhan 2007-11-18 17:40:44 UTC
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, ...)
Comment 5 Victor Vasiliev 2007-11-18 18:55:12 UTC
(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
Comment 6 Robert Leverington 2007-11-18 19:09:47 UTC
(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.
Comment 7 Roan Kattouw 2007-11-18 19:39:47 UTC
(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. 

Comment 8 Yuri Astrakhan 2007-11-18 20:08:56 UTC
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.
Comment 9 CBM 2007-11-18 22:44:53 UTC
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.
Comment 10 Yuri Astrakhan 2007-11-19 00:43:32 UTC
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.
Comment 11 Victor Vasiliev 2007-11-23 18:41:34 UTC
Fixed in r27626, r27630.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links