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.