Last modified: 2014-01-29 04:15:20 UTC
Click the v gadget on a Flow board post and choose Post history, and you're taken to, e.g. http://ee-flow.wmflabs.org/w/index.php?title=Special:Flow/Sandbox&topic[postId]=05055efbee7cb62ef835fa163e68c4ac&workflow=05055eed28a8b62ef835fa163e68c4ac&action=post-history The "subpage" is the page of the Flow board (Sandbox in the example), and the workflow and the topic[postId] are the same UUID. If I change to another, existing page like Main_Page, I get Unexpected non-MediaWiki exception encountered, of type "Exception" exception 'Exception' with message 'title' in /srv/mediawiki/extensions/Flow/includes/Model/Workflow.php:139 Stack trace: #0 /srv/mediawiki/extensions/Flow/includes/WorkflowLoader.php(91): Flow\Model\Workflow->matchesTitle(Object(Title)) #1 /srv/mediawiki/extensions/Flow/includes/WorkflowLoader.php(43): Flow\WorkflowLoader->loadWorkflowById(Object(Title), Object(Flow\Model\UUID)) ... I thought you could display a post's history independent of its workflow, but if I remove &workflow=xxxxx, I get the exception: Unexpected non-MediaWiki exception encountered, of type "Exception" exception 'Exception' with message 'No postId provided' in /srv/mediawiki/extensions/Flow/includes/Block/Topic.php:306 Stack trace: #0 /srv/mediawiki/extensions/Flow/includes/Block/Topic.php(264): Flow\Block\TopicBlock->renderPostHistory(Object(Flow\Templating), Array, true) #1 /srv/mediawiki/extensions/Flow/templates/topiclist.html.php(45): Flow\Block\TopicBlock->render(Object(Flow\Templating), Array, true) But I did provide a postId, so the exception is misleading. It seems post-history needs both a workflow and a topic[postId], even though they're the same. I tried to figure out how this should work by reading URLS and INITIAL_WORKFLOWS and got confused.
For the first half, i will look into it in the morning. The second half, i probably need to update the various documentation in the root of the directory. For the most part those were written pre-implementation as a way to collect my thoughts on how the implementation should work. As with any documentation, that actual implementation ends up differing as we learn more about the problem space. As it stands currently, the following parameters are accepted by Special:Flow action: This is a string representing the type of action to take. What happens when an action is called depends on the blocks created for the definition. workflow: This is a string 32 char hex id of the specific workflow being referenced. If not provided we load the default workflow specified by the definition. definition: This is a string representing a workflow definition. If not provided this defaults to 'discussion'. Nested parameters, like topic[postId] are parameters for a specific type of block. In this case the topic block. About the postId and the workflowId being the same, this is in part an optimization and simplification in the backend. When we create a new topic we create a Workflow instance with the 'topic' definition. In addition to this workflow we need to create revision to represent the first topic title. This is the optimization, we reuse the uuid of the workflow as the first revision. This simplifies needing to lookup the value, and we still know it will be unused. We can probably default the value of postId to the workflow if not provided when the action is 'history'. Due to the order of loading it would be a bit of a hack to go the other direction. This is also probably much longer than necessary, but perhaps is usefull background information.
Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/265
This bug is super old – can someone please check if it's still occurring and, if not, close this out?
These were basically about the error responses to user input errors being raw exceptions. Now we return a page that says: Error Invalid value was provided for loading flow content They could perhaps still be more helpful, for example instead of just erroring because the workflow and the provided page don't match, we could display the error and link the user to the right place. I think the current state solves the original bug though.
