Last modified: 2014-09-09 02:39:00 UTC
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.
in backlog: https://trello.com/c/CDULbpKM
This bug does not seem actionable. The tests on beta labs are passing and I don't think we should be worrying about Flow test pages. Yes we might hit issues on that browser test if user talk pages all become Flow enabled but since they are not let's worry about that when it happens to keep us focused. Right now there is no bug right? This is a "in future there might be a bug" Note bug 60808 captures the issues with action=edit
