Last modified: 2013-07-13 17:59:35 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 25928 - AbuseFilter API: output problems with aflprop=details
AbuseFilter API: output problems with aflprop=details
Status: RESOLVED WORKSFORME
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/api.php?act...
:
Depends on:
Blocks: noncoreapi
  Show dependency treegraph
 
Reported: 2010-11-14 21:08 UTC by Gurch
Modified: 2013-07-13 17:59 UTC (History)
4 users (show)

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


Attachments

Description Gurch 2010-11-14 21:08:35 UTC
When requesting details of an abuse log item (with an aflprop value containing "details"), often the request returns after a few seconds with just the following (with xml format selected):

<?xml version="1.0"?>

When it does return it is very slow even for the default item limit (10) and can often return as above even with a limit of 1.

Currently the maximum limit is 500. This is no problem at all when fetching only the basic log information (no "details" in aflprop). It is evidently a problem when details are requested.

Two things should be done to address this:

* Add an "aflid" parameter, that overrides other filtering parameters and retrieves the single abuse log entry with that ID. Make aflprop=details valid only when this parameter is specified. This should fix the performance issue, whilst still allowing details to be fetched, and as a bonus allow easier retrieval of a single abuse log entry.

* Investigate whether the blank output as above is sometimes due to an error condition, rather than a timeout of some sort. (The fact that the query in the URL field sometimes works and sometimes doesn't, presumably dependent on whatever the last abuse log entry was, suggests this).
Comment 1 Marius Hoch 2013-07-13 17:59:35 UTC
I can't reproduce any of these problems. I guess the new logging system (https://gerrit.wikimedia.org/r/42501) I've introduced in late February is the cause for this (at least it was one of its purposes to accelerate log detail access).

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


Navigation
Links