https://office.wikimedia.org/wiki/Talk:Staff_handbook/Key_culture displays
No such action
<flow-action-unsupported>
Return to Main Page.
The action is view as can be verified in the JS console or the page source. When manually specifiying a different action (such as https://office.wikimedia.org/w/index.php?title=Talk:Staff_handbook/Key_culture&action=edit) it just redirects to the canonical URL.
Other Flow pages work fine.
https://office.wikimedia.org/wiki/Talk:Staff_handbook/Key_culture is wikitext in DB (https://office.wikimedia.org/w/api.php?titles=Talk:Staff_handbook/Key_culture|Talk:Staff_handbook/Benefits&prop=info&action=query), but prop=revisions thinks it's flow-board (https://office.wikimedia.org/w/api.php?action=query&prop=revisions&titles=Talk:Staff_handbook/Key_culture&rvprop=ids|user|timestamp|comment|content).
We think this is due to a core change.
Fixed on officewiki by populating rev_content_model for revisions associated with namespaces in which Flow is enabled (3k rows). Not yet fixed on cawiki, where the offending code will hit tomorrow; we'd have to update a lot more rows for that (17.5k) so I've asked @Springle and @jcrespo for permission on IRC before I go ahead and do that.
The offending core change is https://gerrit.wikimedia.org/r/#/c/222043
Why did the patch get merged with a denormalized model? We were agreeing here to use a more normal model: https://gerrit.wikimedia.org/r/#/c/221306/ Quoting Tim Starling: "the range configuration information could be stored in a table rather than in configuration, and then it can easily be under control of the upgrade script."
I understand this was an emergency, but I would expect this to be only a temporary patch. This will work for smaller wikis, but will not scale for enwiki or all wikis in general. We do *not* use compression for the main production servers.
If by "the patch" you mean https://gerrit.wikimedia.org/r/#/c/222043, probably because it has nothing to do with https://gerrit.wikimedia.org/r/#/c/221306/ besides both being inspired by the same issue.
222043, merged, fixes a bug with the interpretation of "NULL as default" in the existing model: the logic for determining the default for setting versus fetching wasn't the same, such that the fetched default was wrong whenever the top revision had a non-default model. The existing model still suffers from T104033, though.
221306, not merged, is about actually solving T104033 by eliminating "NULL as default" all together. It looks likely to take a lot more work, though. The current patch would result in a large increase in database size. Tim's suggestion on 221306 that you quoted is a different idea for solving T104033.
The page https://office.wikimedia.org/wiki/Talk:Staff_handbook/Key_culture is displayed correctly.
For cawiki, enwiki, and testwiki(wmflabs) - I cannot find the similar discrepancy: page_content_model ='flow-board' and rev_content_model='wikitext'.