Page MenuHomePhabricator

Make the WikiProject or Page title field required for Page Assessments
Closed, ResolvedPublic3 Story Points

Description

On Page Assessments, you need to fill in either the WikiProject field or the Page title field before clicking Search. There's no use case that would require just searching for a namespace without WikiProject or Page title.

When a user clicks Search without filling in at least one of the other fields, don't run a query. Just display a red warning: "WikiProject or Page title field required"

Also make sure that the results are ordered alphabetically.

Also, this will probably mean that we don't want to have the page do a default query at all when you first load the page.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 22 2017, 3:33 AM

bd808 found this:

1SELECT pap_project_title AS `project`,
2 pa_class AS `class`,
3 pa_importance AS `importance`,
4 rev_timestamp AS `timestamp`,
5 page_title,pa_page_revision AS `page_revision`,
6 page_namespace
7FROM `page_assessments`
8JOIN `page_assessments_projects` ON ((pa_project_id = pap_project_id))
9JOIN `page` ON ((pa_page_id = page_id))
10JOIN `revision` ON ((page_id = rev_page AND pa_page_revision = rev_id))
11WHERE page_namespace = '2' LIMIT 101

https://en.wikipedia.org/wiki/Special:PageAssessments?project=&namespace=2&page_title= is working now. It was failing before. My guess is that the data warmed up a bit.

https://en.wikipedia.org/wiki/Special:PageAssessments?project=&namespace=2&page_title=&limit=1 returns faster (though with an off-by-one error?). Broadly, the errors may be a pagination issue, where there's a large data set and "obscure" namespaces cause a lot of row scanning, which often results in queries getting killed (timing out) for exceeding a maximum execution time. I believe we still have this issue with (for example) Special:Contributions for users with lots of edits, when you try to filter to uncommon namespaces with a high per-page result set limit.

bd808 added a subscriber: bd808.Jun 22 2017, 4:21 AM

Original exception was:

Wikimedia\Rdbms\Database::query: lost connection to 10.64.48.20; reconnected:
#0 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php(2905): Wikimedia\Rdbms\Database->query()
#1 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php(2881): Wikimedia\Rdbms\Database->doCommit()
#2 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php(756): Wikimedia\Rdbms\Database->commit()
#3 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1084): Wikimedia\Rdbms\Database->close()
#4 (): Closure$Wikimedia\Rdbms\LoadBalancer::closeAll()
#5 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1485): call_user_func_array()
#6 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1085): Wikimedia\Rdbms\LoadBalancer->forEachOpenConnection()
#7 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1076): Wikimedia\Rdbms\LoadBalancer->closeAll()
#8 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1665): Wikimedia\Rdbms\LoadBalancer->disable()
#9 (): Wikimedia\Rdbms\LoadBalancer->__destruct()
#10 {main}

https://en.wikipedia.org/wiki/Special:PageAssessments?project=&namespace=3&page_title=&limit=4 resulted in:

[WUtF3ApAEK8AAECsXNcAAABR] 2017-06-22 04:22:48: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

MariaDB [enwiki_p]> select count(*) from page_assessments;
+----------+
| count(*) |
+----------+
| 16787476 |
+----------+
1 row in set (16.25 sec)

Decent number of rows. But, without any joins, it was able to scan them all pretty quickly on the replica database. Hmmm.

Filed as T168600: Special:PageAssessments with specified limit is off by one.

Broadly, the errors may be a pagination issue, where there's a large data set and "obscure" namespaces cause a lot of row scanning, which often results in queries getting killed (timing out) for exceeding a maximum execution time. I believe we still have this issue with (for example) Special:Contributions for users with lots of edits, when you try to filter to uncommon namespaces with a high per-page result set limit.

This is mostly referring to T33197#356905.

kaldari moved this task from Untriaged to To be estimated/discussed on the Community-Tech board.
kaldari added a subscriber: kaldari.

Confirmed the bug.

Maybe we should restrict it to require a project or title.

DannyH renamed this task from PageAssessments search for specific namespace yields DB error in one circumstance to Make the WikiProject or Page title field required for Page Assessments.Jun 27 2017, 11:17 PM
DannyH updated the task description. (Show Details)
DannyH updated the task description. (Show Details)
kaldari updated the task description. (Show Details)Jun 27 2017, 11:24 PM
kaldari triaged this task as Normal priority.
kaldari set the point value for this task to 3.
MaxSem claimed this task.Jul 11 2017, 10:02 PM
MaxSem added a project: Community-Tech-Sprint.

Change 364635 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/PageAssessments@master] Disallow slow query when filtering only by namespace

https://gerrit.wikimedia.org/r/364635

Change 364635 merged by jenkins-bot:
[mediawiki/extensions/PageAssessments@master] Disallow slow query when filtering only by namespace

https://gerrit.wikimedia.org/r/364635

kaldari closed this task as Resolved.Jul 12 2017, 8:55 PM

This isn't exactly the solution requested in the description, but it's pretty close. Since Special:PageAssessments is a QueryPage, it would actually take some refactoring to prevent it from doing a default query. The current solution seems like a good improvement though. If anyone feels strongly that we should just get rid of the default query entirely, feel free to reopen.