We should do a full conversion test of LQT to Flow, at testwiki, to demonstrate that all redirects/history/etc work as intended, before attempting at mediawiki.org T92303: Convert LQT pages on MediaWiki.org to Flow (tracking)
(Tests ongoing at
and others)
I retested locally (with a fresh board) on 1.26wmf3, and it still works perfectly. I suspect this is a master/slave issue (I tried to Do The Right Thing here, but I'm not testing with a true master/slave setup locally).
I know there was a couple attempts to introduce fake slave lag on MediaWiki-Vagrant (e.g. 29fdf3edf61f7f5cb21ff99c7199c06e3d5252c7), but they were both reverted AFAICT.
I haven't figured this out yet. A new set of eyes would be helpful.
It works fine on Beta:
and locally (even with a fake master/slave setup, and with and without fakeSlaveLag):
One thing that hasn't been fully explored is whether it's specific to User_talk:Hazard-SJ's history (page moves, initial failed conversion for separate reasons, etc.). We could try another page on testwiki in production.
But first I'd like someone else to take a look at it, before we try again in production.
Thanks.
After some debugging, it looks like the issue is perhaps just an artifact of a previous failed import.
The flow_workflow table contains a discussion workflow for User_talk:Hazard-SJ pointing to page_id 39181. This is the page id of the LQT page. At the begining of the import process this is moved to User_talk:Hazard-SJ/LQT Archive 1 Because this already exists, TalkpageImportOperation::import() gets false for $state->boardWorkflow->isNew() and never tries to create a page for it using ensureFlowRevision().
Matt you might remember best, but my impression is that this was caused by the initial failed import when it was not moving the LQT page out of the way, but rather usurping it with a flow revision on top of the flow revision. With the various fixes in the code base since then I don't think we should be expecting this to happen again. It should be safe to delete both workflows that exist (one topic and one discussion) from the flow_workflow table for workflow_wiki = testwiki, workflow_namespace = 3, workflow_title_text = Hazard-SJ and call it a day.
I was just thinking about this, perhaps I overlooked something when writing the code for moving boards because if everything was working properly even though that workflow is wrong, it should get updated to point to the new User_talk:Hazard-SJ/LQT Archive 1 when the page move happens.
After I repaired the broken Flow board, it was the original LQT page again. That means when the import script did the move, that content model wasn't flow-board, so the Flow hooks ignored it.
Hmm, i wonder if we should be checking for a workflow with matching page id and not just the content model? It seems like the workflow should still get repointed if moved, even if its not the current top revision.
@EBernhardson, yeah, I guess this is still necessary for accurate contributions reporting (with the namespace selector) for posts to a Flow board that was moved after it was no longer a Flow board.
Filed as T97568: Update Flow boards for move even if the top revision is no longer a Flow board
This makes sense, and I deleted it:
mysql:research@x1-analytics-slave [(none)]> select workflow_type, workflow_namespace, workflow_title_text from flowdb.flow_workflow WHERE workflow_page_id = '39181' OR (workflow_namespace = 3 AND workflow_title_text = 'Hazard-SJ'); Empty set (0.04 sec)
After that, it does not seem to be cached (even without an explicit cache clear):
mattflaschen@terbium:~$ mwscript eval.php --wiki=testwiki
> $container = Flow\Container::getContainer();
> $container->extend( 'memcache', function( $memcache, $c ) {$c['memcache.purge_backup'] = $memcache; return new HashBagOStuff; } );
> $hashBag = $container['memcache'];
> $loader = $container['factory.loader.workflow'];
> $title = Title::newFromText( 'User talk:Hazard-SJ' );
> $workflow = $loader->createWorkflowLoader( $title )->getWorkflow();
> echo $workflow->isNew();
1Never mind, that was a mistake (that session is deliberately not using the real cache).
It is cached:
mattflaschen@terbium:~$ mwscript eval.php --wiki=testwiki > $container = Flow\Container::getContainer(); > $loader = $container['factory.loader.workflow']; > $title = Title::newFromText( 'User talk:Hazard-SJ' ); > $workflow = $loader->createWorkflowLoader( $title )->getWorkflow(); > var_export( $workflow->isNew() ); false
Finally:
The "Did not find thread with conditions" at the end is not an error. It's just debugging code indicating it's done paging.
Talk:LQT (a fresh conversion) also went fine (see end). However, after that Talk:Poem failed:
Talk:LQT
This is a similar error, but can't be the same cause, since the original issue on Hazard-SJ never happened on Talk:Poem.
mysql:research@x1-analytics-slave [(none)]> select workflow_type, workflow_namespace, workflow_title_text from flowdb.flow_workflow WHERE workflow_title_text LIKE '%Poem%'; Empty set (0.02 sec)
Change 207726 had a related patch set uploaded (by Mattflaschen):
Change ensureFlowRevision to use Status and not check summary
When https://gerrit.wikimedia.org/r/207726 is merged, we should SWAT that out, then try again.
Change 207726 merged by jenkins-bot:
Change ensureFlowRevision to use Status and not check summary
I think Talk:Poem failed because allowCreation didn't succeed. It uses $mustNotExist = true by default, which is right, but I think its existence check was out of date so it was wrongly still seeing the LQT page we had just moved out of the way.
Patch coming for that.
Change 207835 had a related patch set uploaded (by Mattflaschen):
Make sure allowCreation existence status is right, use Status
Change 207835 merged by jenkins-bot:
Make sure allowCreation existence status is right, use Status
Change 207981 had a related patch set uploaded (by Mattflaschen):
Change ensureFlowRevision to use Status and not check summary
Change 207981 merged by jenkins-bot:
Change ensureFlowRevision to use Status and not check summary
Change 207984 had a related patch set uploaded (by Mattflaschen):
Make sure allowCreation existence status is right, use Status
Change 207984 merged by jenkins-bot:
Make sure allowCreation existence status is right, use Status
The header edit is somehow in the wrong order for Talk:Ballet. Everything else looks good to me, so I'll take a look at that.
mysql:research@x1-analytics-slave [flowdb]> SELECT LOWER(HEX(rev_id)), rev_type, LOWER(HEX(rev_parent_id)), LOWER(HEX(rev_type_id)), rev_change_type FROM flow_revision WHERE LOWER(HEX(rev_id)) IN ('0534326fc7b81d41212148', '0534326fc72c1e93188bed') ORDER BY LOWER(HEX(rev_id)) DESC;
+------------------------+----------+---------------------------+-------------------------+-----------------+
| LOWER(HEX(rev_id)) | rev_type | LOWER(HEX(rev_parent_id)) | LOWER(HEX(rev_type_id)) | rev_change_type |
+------------------------+----------+---------------------------+-------------------------+-----------------+
| 0534326fc7b81d41212148 | header | NULL | 0534326fcfd9c931f9e505 | create-header |
| 0534326fc72c1e93188bed | header | 0534326fc7b81d41212148 | 0534326fcfd9c931f9e505 | edit-header |
+------------------------+----------+---------------------------+-------------------------+-----------------+
2 rows in set (0.18 sec)It displays the wrong version of the header because there are two consecutive generated revisions with the same timestamp. The HistoricalUIDGenerator should work and have the correct ordering if the timestamps are different. However, if not it can be in the wrong ordering.
The initial header takes the timestamp from the move time (since that's the last revision of the archived page), and the scripted cleanup revision was taking wfTimestampNow. This caused a race condition where it often worked, but these could be the same time, as happened here.
Change 208065 had a related patch set uploaded (by Mattflaschen):
Set cleanup header revision after original to avoid collisions
Notes - what's tested: