With Gerrit change #151806, the Echo notifications.feature browser tests have a step "another user writes on my talk page" that ends up calling the Mediawiki web API with action=edit title=User_talk:SOMEUSERNAME content=HelloBlahblah.
The API call to change the page content silently fails if the title is a Flow board, which is the default on the Flow team's test servers. You can try it with Special:ApiSandbox
The action=edit API call returns successfully, but if you ask for the content of the page, e.g. with Special:Export or action=query prop=revisions, you'll see that a new revision with new revID is created, the contentmodel remains "flow-board", but the text content is an empty array, not "HelloBlahblah". The moment someone visits the Flow board a new revision is created and its content changes back to being the magic {"flow-workflow":"<UUID>"} JSON for a flow-board.
The Flow team needs to figure out what should happen when someone uses action=edit API on a Flow board. I think it should fail. Flow could "do the right thing" and modify the Flow board's header area, but the model of a new revision for the page doesn't apply, so any client expecting to get a "newrevid" back is gonna have a bad time. Bug 60808 comment 2 asks that action=edit§ion=new create a new topic, but that has similar issues. I think client libraries that wrap the MediaWiki web API, like the browsertest create_page() function, could hide the differences; but Flow should not.
Version: master
Severity: normal