Page MenuHomePhabricator

Flow changes run from update.php failed
Closed, InvalidPublic

Description

I updated ee-flow-extra labs instance to wmf/1.23wmf9 (tip sudo su - vagrant; bash).

php maintenance/update.php crashed

MediaWiki 1.23wmf9 Updater

Going to run database updates for extrawiki
...
Modifying rev_change_type field of table flow_revision ...done.
Modifying rc_source field of table recentchanges ...done.
Modifying rev_change_type field of table flow_revision ...done.
...site_stats is populated...done.
...Update 'populate rev_len and ar_len' already logged as completed.
...Update 'populate rev_sha1' already logged as completed.
...img_sha1 column of image table already populated.
...protocol-relative URLs in externallinks table already fixed.
...fa_sha1 column of filearchive table already populated.
...Update 'FlowInsertDefaultDefinitions' already logged as completed
A database query error has occurred.
Query: SELECT workflow_id,workflow_user_text FROM flow_workflow WHERE (workflow_id > '\0') AND (workflow_user_ip IS NULL) AND (workflow_user_id = 0) ORDER BY workflow_id LIMIT 200
Function: FlowSetUserIp::updateWorkflow
Error: 1054 Unknown column 'workflow_user_ip' in 'where clause' (10.4.1.75)

The glitch might be that the ordering is wrong.
Flow's db_patches/patch-remove_usernames.sql adds this column, maybe it hasn't run yet.

Or it could be ee-flow-extra's wacky DB setup where it's using a different DB. extrawiki only has a blobs table.


Version: master
Severity: normal

Details

Reference
bz59607

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:42 AM
bzimport set Reference to bz59607.
bzimport added a subscriber: Unknown Object (MLST).

bingle-admin wrote:

The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/679, but people from the community are welcome to contribute here and in Gerrit.

The problem was probably extrawiki's DB setup with a separate flowdb on the "cluster."

$ mysql flowdb
(21:28) root@localhost:[flowdb]> source extensions/Flow/db_patches/patch-remove_usernames.sqlQuery OK, 10 rows affected (0.56 sec)

then rerun maintenance/update.php

This seems hard to fix unless there's some magic comment that will use $wgFlowExternalStore and $wgFlowDefaultWikiDb to target the right cluster.

BTW the FlowSetUserIp script doesn't output anything, there's no indication when it successfully runs

That's a problem with core updater.

Maintenance scripts (addPostDatabaseUpdateMaintenance) are usually fine as they fetch the correct DB connection. DB patches are run against core database though.

We're fine in production since we always manually do DB updates. Most 3rd party setups will be fine as well, since they'll likely not store data on a separate DB.

However, it'd be best if we could figure out a way to let DatabaseUpdater properly apply patches to the correct DB. Probably not easy though: what happens if some patch fails - what do we roll back? etc...