Page MenuHomePhabricator

[Regression] Recent Changes on MediaWiki.org doesn't display more than 50 past edits
Closed, ResolvedPublic

Description

I've even changed the filter to show last 5000 changes, in the past 30 days, and it doesn't display more than the default 50

See screenshot when not logged-in (being logged-in or not doesn't seem to make a difference):

It was working correctly yesterday at least

Details

Related Gerrit Patches:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Ciencia_Al_Poder triaged this task as Unbreak Now! priority.Nov 15 2017, 10:33 AM

I'm gonna be bold and mark it as UBN since it's a regression (apparently) of 1.31.0-wmf.8, being deployed to major wikipedias today, to attract attention at least

Restricted Application added subscribers: Liuxinyu970226, Jay8g, TerraCodes. · View Herald TranscriptNov 15 2017, 10:33 AM
Trizek-WMF added a subscriber: Trizek-WMF.EditedNov 15 2017, 10:50 AM

It is also broken on test wiki, which means it may be in the deployment train. Clearly UBN.

The Global collaboration team has been informed about it.

This only affects the new filters, not the old filters. The issue seems that the URL is not updating when the limit is changed. If I add it manually to the URL it works.

git bisect says b8a10e6dcf00da3519ccb9e43d1c2ce0db422557 is the first bad commit.

I don't know how it breaks things. It seems to revert clearly, so that could be done as a quick fix.

git bisect says b8a10e6dcf00da3519ccb9e43d1c2ce0db422557 is the first bad commit.
I don't know how it breaks things. It seems to revert clearly, so that could be done as a quick fix.

I talked to Moriel and we discovered that it breaks things by removing "excluded" parameters (which includes "days" and "limit") from the URL both in the address bar and in the AJAX request. The latter was not intended.

She says there should be no negative side effects from reverting that commit, so I'm going to SWAT a revert in half an hour.

Change 391613 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] Revert "RCFilters: Remove excluded params from URL"

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

Change 391614 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@wmf/1.31.0-wmf.8] Revert "RCFilters: Remove excluded params from URL"

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

Change 391614 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.8] Revert "RCFilters: Remove excluded params from URL"

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

Change 391613 merged by jenkins-bot:
[mediawiki/core@master] Revert "RCFilters: Remove excluded params from URL"

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

Mentioned in SAL (#wikimedia-operations) [2017-11-15T19:19:49Z] <catrope@tin> Synchronized php-1.31.0-wmf.8/resources/src/mediawiki.rcfilters/mw.rcfilters.UriProcessor.js: T180577 (duration: 00m 49s)

Ciencia_Al_Poder closed this task as Resolved.Nov 15 2017, 8:43 PM
Ciencia_Al_Poder assigned this task to Catrope.

It works now on mediawiki.org, so I assume this can be resolved now. Thanks!

jmatazzoni reopened this task as Open.Nov 15 2017, 9:12 PM
jmatazzoni added a subscriber: jmatazzoni.

Thanks for your participation @Ciencia_Al_Poder. But it's safer to let our QA person check for sure that this is completely fixed, so I'm reopening to let that process play out.

greg added a subscriber: greg.Nov 15 2017, 11:51 PM

Given the UBN! priority and the fact that blockers to the train, well, block the train, can that happen sooner than later? ASAP would be good (again, UBN!).

Checked in testwiki and cawiki (wmf.8) - all is working as expected.

Etonkovidova closed this task as Resolved.Nov 16 2017, 12:31 AM