If I understand correctly, the summary is something like "Create a maintenance script that lets a wiki be in a clean state after Flow uninstallation". @DannyH raised the concern that Flow leaves wikis dirty.

Some things are clear.

• After uninstalling Flow, no fatal errors should be produced by merely visiting some URL. (Is this the kind of "serious error" Danny meant?)

Some questions are left about requirements.

• Whether to assume that former topics are exported/converted to wikitext. (Personally I'd say no, but the Flow developers have been very keen on exporting even unrequested test Flow pages before uninstalling.)
• Whether to handle incoming links in some way or just let them 404/whatever.
• Whether to do something about logs. Flow doesn't seem to have its own log type, but it injects some Flow-specific stuff.

The solution to the latter can be as simple as unregistering the Topic namespace and registering a log entry about deletion of a namespace 0 page titled like "Topic:Smtt99p7yp47d4wc". Then any visitor would see the standard excerpt from the deletion log upon visiting related URLs, as long as the title index.php parameter is included.

If testing such a script on Commons is too much, the list at T188812#4020445 may provide some good test cases (e.g. small wikis with less than 10 topics where Flow has not been used in months).

Just to toss out another idea, is it possible to delete or sanitize the objectionable log entries?

In T188806#4020483, @Alsee wrote:

Just to toss out another idea, is it possible to delete or sanitize the objectionable log entries?

That's possible, although we'd first need to understand why it's even needed. Let's see an example log entry:

MariaDB [frwikiquote_p]> select * from logging join page ON page_id = log_page and page_namespace = 2600 LIMIT 1 \G
*************************** 1. row ***************************
               log_id: 62315
             log_type: lock
           log_action: flow-lock-topic
        log_timestamp: 20160623151111
             log_user: 1639
        log_namespace: 2600
            log_title: T6d5zzuxhu53xi61
          log_comment: marqué comme résolu
           log_params: a:1:{s:7:"topicId";s:16:"t6d5zzuxhu53xi61";}
          log_deleted: 0
        log_user_text: Lykos
             log_page: 34390
              page_id: 34390
       page_namespace: 2600
           page_title: T6d5zzuxhu53xi61
    page_restrictions:
         page_counter: 0
     page_is_redirect: 0
          page_is_new: 1
          page_random: 0.12527787493
         page_touched: 20160622164152
   page_links_updated: 20160624080929
          page_latest: 240937
             page_len: 1
page_no_title_convert: 0
   page_content_model: flow-board
            page_lang: NULL
1 row in set (1.09 sec)

If the log_params columns only contain Flow internals, we only need to keep the log_comment. The log entry could be in any type whose log formatter allows a free text field.

But are such log entries visible only when searching by user name? Special:Log doesn't allow to filter by this log_type. If the namespace 2600 disappeared, visiting [[Topic:T6d5zzuxhu53xi61]] would not show this log entry because notices such as moveddeleted-notice and recreate-moveddeleted-warn are shown only for certain log types:

			LogEventsList::showLogExtract( $out, [ 'delete', 'move' ], $this->mTitle,

or

			$logTypes = [ 'delete', 'move', 'protect' ];
[...]
			Hooks::run( 'Article::MissingArticleConditions', [ &$conds, $logTypes ] );
			LogEventsList::showLogExtract(
				$outputPage,
				$logTypes,
				$title,

Note that one of the phrases in DannyH's post to Commons was hidden by a wiki-typo (fix seen in this edit). The last sentence in the quoted text in the task description should read:

"If the extension was completely uninstalled, then there's no software that recognizes what those links are, so clicking on them would cause a fatal exception error, and attempting to undelete them could cause a serious error." [emphasis added]

FYI.

In T188806#4021450, @Dcljr wrote:

"If the extension was completely uninstalled, then there's no software that recognizes what those links are, so clicking on them would cause a fatal exception error, and attempting to undelete them could cause a serious error." [emphasis added]

Thanks, I had missed that word although I suspected "serious error" referred to a fatal error/exception. That would definitely be a bug: it should be reported separately with precise steps to reproduce and available workarounds. (With or without exporting to wikitext, with or without removing entries from page and logging table, etc.)

While I applaud @Nemo_bis for working on this, I would like to point out, that he is not the one able to run the scripts, he is not the one getting a call in the night if something goes wrong, he is not the one who has to dive into the production servers to debug something after that call, he does not have a multi datacenter setup to test against, etc etc etc.

There seems to be this idea that the work stops with the patch. It does not. There are deployers, people on call and the employees who have to deal with the issues found in production (which is what happened last time). Now I'm not calling Nemo incompetent. Far from it. But reality is that rewriting stuff introduces significant risks when the system is complex (and ALL OUR SYSTEMS ARE COMPLEX).

The team recognised this, because it had lived through it (when they did it for en.wp and meta). That doesn't make it impossible, just HIGHLY expensive. They seem to have made a reasoned choice here, and the communities are asking for 10-15 times more resources to be spent, basically because they are offended. I do not find that very healthy honestly and it makes 0 sense from a technical perspective. It's just very expensive social pandering to the community.

@TheDJ thank you.

rewriting stuff introduces significant risks when the system is complex

THANK YOU for explaining why T188577 shouldn't be built. No one wants it, it has zero technical or social value. Deploying it on Commons would increase the immediate risk by deploying useless new code, and it would increase the ongoing risk putting Flow into unique and worthless new state.

THANK YOU for explaining how critically important it is to UNINSTALL FLOW when it's unused and there's complicated new software being deployed on it. Cleaning up the logs is one small simple thing, new development on flow is big and complicated. When things are big and complicated, bugs are inevitable.

In T188806#4027749, @TheDJ wrote:

While I applaud @Nemo_bis for working on this, I would like to point out, that he is not the one able to run the scripts, he is not the one getting a call in the night if something goes wrong, he is not the one who has to dive into the production servers to debug something after that call, he does not have a multi datacenter setup to test against, etc etc etc.

There seems to be this idea that the work stops with the patch. It does not.

Just to make it clear, I agree. Besides, I've not assigned this task to myself. I just think it's worth helping flesh out Gryllida's idea, although I'm surprised there's even a need for such a thing.

Should we reinstall Flow on enwiki and metawiki and set $wgFlowReadOnly to true on those 2 wikis then, as we did for Commons?

In T188806#4071715, @GeoffreyT2000 wrote:

Should we reinstall Flow on enwiki and metawiki

Err, no. Whatever problems the uninstallation caused, they were already solved or digested (although it would be nice to list relevant reports). Going back is just begging for more problems.