Page MenuHomePhabricator

Newcomer tasks: module preview showing "0 edits"
Closed, ResolvedPublicBUG REPORT


In T235810: Newcomer tasks: mobile preview, we made the mobile preview such that it would show the number of edits in the main namespace done by human users (not bots) that happened the day before. Currently, all four of the wikis where newcomer tasks is deployed are showing "0". See screenshot below from Arabic Wikipedia.

IMG_8616.jpg (1×750 px, 109 KB)

Event Timeline

It looks like there is something up with the endpoint for retrieving results: returns


Change 569899 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Use AQS data from two months ago

I've posted a patch that switches to using data from 2 months ago. That should solve the problem but we might consider also having a different UX when the number of edits returned is 0.

2020-02-04 09:37:31 	<kostajh> 	hi, I'm wondering if something has changed with AQS recently. (Context is T244164)
2020-02-04 09:37:32 	<stashbot> 	T244164: Newcomer tasks: module preview showing "0 edits" -
2020-02-04 09:37:51 	<kostajh> 	specifically, used to show results
2020-02-04 09:38:58 	<kostajh> 	mm, looks like the last data is from 31 December.
2020-02-04 09:39:29 	<elukey> 	kostajh: Hi! yes we still need to update aqs to the new snapshot
2020-02-04 09:39:38 	<elukey> 	(that includes january's data)
2020-02-04 09:40:03 	<elukey> 	does it work for data prior to that?
2020-02-04 09:40:06 	<kostajh> 	elukey: ok, thanks. Is there a task I can follow fo rthat?
2020-02-04 09:40:20 	<kostajh> 	elukey: yes it does.
2020-02-04 09:41:10 	<kostajh> 	the problem is that we show data from "1 month ago" so currently all of "number of edits" widgets show 0, e.g.
2020-02-04 09:41:41 	<kostajh> 	a super hacky workaround, since we're not too concerned about accuracy, is to show data from "2 months ago" (or 3 months ago), but depends on the timeline of updating AQS
2020-02-04 09:42:40 	<elukey> 	kostajh: is this a feature for mobile or the apps? I wasn't aware of it.. problem is, we should be able to update aqs this week, but IIUC the problem will re-occur every month no?
2020-02-04 09:43:40 	<kostajh> 	elukey: mobile web and desktop
2020-02-04 09:44:07 	<kostajh> 	elukey: we haven't had a problem with it yet, the code went live in the third week of October
2020-02-04 09:44:24 	<kostajh> 	or, maybe we have had a problem and no one noticed
2020-02-04 09:44:32 	<elukey> 	kostajh: yeah I think so :(
2020-02-04 09:45:26 	<kostajh> 	elukey: is the process for updating AQS documented somewhere? if I understand, you manually load data each month, but sometimes this doesn't happen at the beginning of the month?
2020-02-04 09:46:11 	<kostajh> 	so if we update our code to query for one day of edits from 2 months ago, we should be safe?
2020-02-04 09:47:45 	<elukey> 	kostajh: we have jobs in hadoop that every month create, but we need to make a code change in AQS to update the data source since it is not a simple update (we calculate every month the whole dataset)
2020-02-04 09:47:50 	<elukey> 	so we need to test etc..
2020-02-04 09:48:00 	<kostajh> 	k
2020-02-04 09:48:31 	<elukey> 	2 months seems safe, but please note the AQS is not supported as mediawiki is
2020-02-04 09:48:49 	<elukey> 	namely, we keep it up as best as possible following best SRE practices etc..
2020-02-04 09:49:02 	<kostajh> 	sure
2020-02-04 09:49:06 	<elukey> 	but it is a service that can go down, and that doesn't page SRE etc..
2020-02-04 09:49:23 	<elukey> 	we get alarms of course :)
2020-02-04 09:49:36 	<elukey> 	but I woudn't use it for something super impactful for users
2020-02-04 09:49:39 	<kostajh> 	yeah
2020-02-04 09:49:53 	<kostajh> 	so, we probably need something else in the UI to show when the number comes back as 0
2020-02-04 09:49:56 	<kostajh> 	ok, thanks :)
2020-02-04 09:50:32 	<elukey> 	we can discuss the use case for sure, but I would reach out to nuria first (my manager)
2020-02-04 09:51:39 	<kostajh> 	I think the existing setup is fine, we can make our UI a bit more resilient
2020-02-04 09:52:15 	<elukey> 	another question is how much traffic does thing bring to AQS
2020-02-04 09:52:26 	<elukey> 	I didn't notice anything horrible in traffic graphs
2020-02-04 09:52:31 	<elukey> 	but do you expect it to grow?
2020-02-04 09:54:23 	<kostajh> 	elukey: not very high traffic at the moment. It's shown to newly registered users on select wikis. has a table of where we are deployed
2020-02-04 09:54:47 	<kostajh> 	but, French Wiki and Commons are possible additions
2020-02-04 09:55:06 	<kostajh> 	elukey: also, we cache the result for a day (for all users)
2020-02-04 09:55:27 	<kostajh> 	so actually, we're just hitting that raw URL once per day per wiki.
2020-02-04 09:56:28 	<elukey> 	ack thanks

Thanks @elukey

@MMiller_WMF the number will still show 0 for some time less than 24 hours, because we cache the result of querying AQS for 24 hours and the last cache result was the number 0. But this should be back to normal by tomorrow, and the patch should ensure it doesn't happen again.

Looking at, it seems like the data stops on 31 December.

Right, this will happen again cause data is deployed the first week of the month (been so since these apis were created) as it takes a few days to be computed. Will continue to be the same going forward. You probably need a different level api more geared towards features rather than an API geared towards analytics clients.

Your request is similar to these:T240387: MW REST API Historical Data Endpoint Needs

Change 569899 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Use AQS data from two months ago

I was monitoring the numbers for wmf.20 and wmf.21 - zeroes were not displayed.