Page MenuHomePhabricator

Make Wikidata changes appear quicker in the watchlist on the client
Closed, ResolvedPublic

Description

I have [[de:Hilfe:Suche]] on my watchlist, which is connected with [[d:Q5525084]]. On my watchlist on de.wikipedia I see the two changes from 12:xx UTC, 7 March. But the next change (8:20 UTC, 8 March) is still not on my watchlist. This is now two hours ago, and many other Wikipedia changes are on my watchlist on the top. When this change will eventually appear, it will be somewhere in the middle of a list of changes I already looked at and won't look at again.

This means that I probably won't see that change once it appears on my watchlist (unless I'm really looking for it). The change should appear almost immediatly, otherwise it's useless, at least for users with big watchlists.


Version: unspecified
Severity: major
URL: http://lists.wikimedia.org/pipermail/wikidata-l/2013-March/001940.html
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=45839
https://bugzilla.wikimedia.org/show_bug.cgi?id=46643
https://bugzilla.wikimedia.org/show_bug.cgi?id=46910

Details

Reference
bz45892

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:30 AM
bzimport set Reference to bz45892.
bzimport added a subscriber: Unknown Object (MLST).

probably need more cron jobs.... or part of the issue could be in the job queue part, but I think the dispatcher would be the issue here

https://gerrit.wikimedia.org/r/#/c/52797/ although it might not be that simple or maybe not enough cronjobs.

I assume that this affects also recent changes? I have seen Wikidata changes only sporadically on the fiwiki recent changes list, although I have switched on the option. Currently I don't see any Wikidata changes among the last 500 edits.

http://fi.wikipedia.org/w/index.php?title=Toiminnot:Tuoreet_muutokset&limit=500

Is this bug related the lacking iw links in this article?

http://sv.wikipedia.org/wiki/Casterman

The article was added eight hours ago. It still lacks iw links in or out of it. I remember having added the svwp link at Wikidata, but the history says otherwise.

http://www.wikidata.org/w/index.php?title=Q568077&action=history

This adding by an IP address was done while I was asleep. The added description was done by me a short while ago.

Has the system been ok overnight?

(In reply to comment #5)

Is this bug related the lacking iw links in this article?

http://sv.wikipedia.org/wiki/Casterman

The article was added eight hours ago. It still lacks iw links in or out of
it.
I remember having added the svwp link at Wikidata, but the history says
otherwise.

http://www.wikidata.org/w/index.php?title=Q568077&action=history

This adding by an IP address was done while I was asleep. The added
description
was done by me a short while ago.

Has the system been ok overnight?

Now the IW links are OK. Best of wishes/P

Per, missing iw links are bug 45839.

Thanks. I'll get back to the right bug report then, when I happen upon the bug again. :-)

If https://www.wikidata.org/wiki/Special:DispatchStats can be trusted, the situation is getting worse and worse: the number for "Stalest" seems to increase by 400.000 every day, and I've never seen it going down in the last few days.

This seems to be fine now. Closing.

(In reply to comment #11)

This seems to be fine now. Closing.

Does it? Oldest change to dispatch is still 3 days old.
Are bots running freely?

The DispatchStats have been at 0 for several weeks now. Verifying.

(In reply to comment #13)

The DispatchStats have been at 0 for several weeks now. Verifying.

Denny, I don't understand, why then does https://www.wikidata.org/wiki/Special:DispatchStats *always* have the "Oldest" in "Change log statistics" being *exactly* 72 h before?
If IDs means something, there's currently a 2 millions items backlog.

Nemo, that's a good question. I will forward it to Daniel K., who wrote the code.

As you can see below, in

https://www.wikidata.org/wiki/Special:DispatchStats#Dispatch_statistics

the "stalest" wiki has usually 0 minutes lag, which is what is relevant. I am not sure what the Change log statistics show. Maybe the whole log that is still in memory, whether or not it has been dispatched?

(In reply to comment #15)

the "stalest" wiki has usually 0 minutes lag, which is what is relevant. I am
not sure what the Change log statistics show. Maybe the whole log that is
still
in memory, whether or not it has been dispatched?

Daniel recently rewrote the special page into, which now says «Change log statistics shows the number and the date for the oldest and the most recent items currently in the queue», so it seems it's about current rather than old queue.

Also: «"Lag" is the time between the change last dispatched to the wiki, and the last change performed on Wikidata», so it's correct to infer it equals the lag between submission and dispatch only if the queue follows a FIFO model (does it?).

Now [[d:Special:DispatchStats]] still shows a queue of exactly 3 days in the top section, but only 68116161-67530667 = ~ 600k items instead of 2 millions.

Right now, not exactly 3 days but nearly:

ID Timestamp
Oldest 67541606 17:15, 7 September 2013
Newest 68126934 17:24, 10 September 2013

(In reply to comment #18)

Right now, not exactly 3 days but nearly:

That's because they are pruned by a cronjob every 20 min IIRC.