Maniphest T192577

tools.wmflabs.org/versions shows incorrect data when first alphasorted wiki in a group is on a different version than the rest
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Catrope
	Apr 19 2018, 5:34 PM

Description

The issue

In T192577#4144103, @bd808 wrote:

In T192577#4143744, @greg wrote:

The version tool apparently just checks the first alphasorted wiki in each group (sensible, where else would you stop?).

Correct. The tool reads the wikiversions.json file from noc.wikimedia.org along with the group0 and group1 dblist files. It then prints the version given in the wikiversions.json file for the first item in each dblist. This is a naive common case implementation that assumes that things are always in lock-step across the 3 groups. Anytime we do something a bit funky like hold a single wiki back or push a single wiki ahead it can show incorrect information.

Original report

Right now https://tools.wmflabs.org/versions claims that group1 is on wmf.30, but that's not true. A bunch of wikis were moved from group0 to group1 semi-recently, so maybe it's looking at the wrong wiki as a bellweather?

Related Objects

Mentioned In: R1958:1cbb4aa2694c: Handle mixed version groups
Mentioned Here: R1958:1cbb4aa2694c: Handle mixed version groups

Event Timeline

Catrope created this task.Apr 19 2018, 5:34 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 19 2018, 5:34 PM

[wikimedia-releng] times in BST
15:52 <•thcipriani> Lucas_WMDE: (a little late, but catching up on scrollback) I didn't roll the train forward yesterday due to blockers that were resolved after the window closed, advisorswiki looks like it is a wiki that was added outside of the train process. It ended up at the top of group1 since group1 is all wikis except wikipedia wikis and explicit group0 wikis.
15:53 <Lucas_WMDE> ok thanks
15:53 <Lucas_WMDE> so it’s just an unfortunate accident that advisorswiki happens to be alphabetically at the beginning of group1 so it confused the versions tool
15:53 <•thcipriani> yes, so it seems

Jdforrester-WMF subscribed.Apr 19 2018, 6:07 PM

(I don't think there's a project for the versions tool, but it's @bd808's baby :) )

As tyler said on IRC, this is due to a weird not common situation: We had a bunch of wiki creations yesterday that happened post train. They were created with the new wmf release (.30). The version tool apparently just checks the first alphasorted wiki in each group (sensible, where else would you stop?).

This will be "resolved" when we move the train forward today and will not be an issue unless some other oddity happens with the top alphasorted wiki in each group :)

In T192577#4143744, @greg wrote:

The version tool apparently just checks the first alphasorted wiki in each group (sensible, where else would you stop?).

Correct. The tool reads the wikiversions.json file from noc.wikimedia.org along with the group0 and group1 dblist files. It then prints the version given in the wikiversions.json file for the first item in each dblist. This is a naive common case implementation that assumes that things are always in lock-step across the 3 groups. Anytime we do something a bit funky like hold a single wiki back or push a single wiki ahead it can show incorrect information.

greg renamed this task from tools.wmflabs.org/versions shows incorrect data for group1 to tools.wmflabs.org/versions shows incorrect data when first alphasorted wiki in a group is on a different version than the rest.Apr 22 2018, 6:15 AM

greg lowered the priority of this task from Low to Lowest.

greg updated the task description. (Show Details)

bd808 mentioned this in R1958:1cbb4aa2694c: Handle mixed version groups.Apr 22 2018, 9:17 AM

Mentioned in SAL (#wikimedia-cloud) [2018-04-22T09:19:57Z] <bd808> Update to 1cbb4aa to provide some handling for T192577

bd808 closed this task as Resolved.Apr 22 2018, 9:20 AM

bd808 claimed this task.

tools.wmflabs.org/versions shows incorrect data when first alphasorted wiki in a group is on a different version than the restClosed, ResolvedPublicActions