Train blocker task has wrong navigation to previous train
Closed, ResolvedPublicBUG REPORT
Actions

Assigned To

Authored By

	hashar
	May 15 2023, 4:23 PM

Description

https://train-blockers.toolforge.org/ currently points to wmf.9 task T330215

The Previous: 1.41.0-wmf.8 button should point to T330214: 1.41.0-wmf.8 deployment blockers but it instead points to T326177

That task got a Release Version instead of the tag MW-1.41-notes (1.41.0-wmf.8; 2023-05-08)

Aklapper set Release Version to 1.41.0-wmf.8.

I think that is the reason since the form configuration https://phabricator.wikimedia.org/transactions/editengine/maniphest.task/view/34/ has:

The release details are automatically generated from a template which uses the contents of the Release Date and Release Version fields to dynamically build all of the details for a given deployment cycle.

So I guess when the field got set on T326177#8848980 it ended up being considered part of the series of blocker. There might be some guard to add to the code.

Details

Related Changes in GitLab:

	Title	Reference	Author	Source Branch	Dest Branch
	Avoid linking to wrong previous train task in train blocker tasks	repos/phabricator/extensions!48	aklapper	T336686prevTrain	wmf/stable

Customize query in GitLab

Related Objects

Mentioned Here: rPHEXce33d8fa9ca8: Avoid linking to wrong previous train task in train blocker tasks
T326177: Special:Log/gwtoolset emits DB Query Timeout Error
T330214: 1.41.0-wmf.8 deployment blockers
T330215: 1.41.0-wmf.9 deployment blockers

Event Timeline

hashar created this task.May 15 2023, 4:23 PM

Editing T326177 meant using Form 46: I set the "MediaWiki Version" field; there is no "Release Version" field in that form. See T326177#8848980.

The "Release Version" field (Form 34) is the field used for "deployment blockers" tasks. Thus I'm puzzled by the line Aklapper set Release Version to 1.41.0-wmf.8.

There might be some guard to add to the code.

Could you elaborate which codebase this refers to?

phabricator/extensions/src/customfields/ReleaseDetailsCustomField.php in GitLab:

// dirty manual query of the custom field storage table to get the value
// for the release.version field for the previous and next version

Aklapper updated the task description. (Show Details)Mar 9 2025, 10:57 AM

Aklapper updated the task description. (Show Details)

SELECT CONCAT('https://phabricator.wikimedia.org/T',t.id), cfs.fieldValue FROM phabricator_maniphest.maniphest_customfieldstorage cfs INNER JOIN phabricator_maniphest.maniphest_task t ON cfs.objectPHID = t.phid WHERE cfs.fieldIndex = "jdY7Vi9O2KUP" LIMIT 800;
shows that the Release Version custom field is the same field (just rebranded) as the MediaWiki Version field which can be filled in for production errors.

So things can go wrong at any time for the "previous" link when any production error task has been filed with that "previous version" value in the meantime.

Code in ReleaseDetailsCustomField simply goes for
SELECT objectPHID, fieldIndex, fieldValue FROM phabricator_maniphest.maniphest_customfieldstorage WHERE fieldIndex = "jdY7Vi9O2KUP" AND fieldValue in ("1.44.0-wmf.16", "1.44.0-wmf.18");
without further filtering task results which might be more than 2 (previous, next) tasks.