Hey László,
The point you're missing here is that a task in a start-state has a different purpose than one in a task-node (which is, admittedly, not very clear from the documentation, but could be derived from this section).
If you look at the jPDL definition, you'll see that there are only two node types that support tasks:
- task-node: for human tasks that are part of your business process and are assigned, started and ended while the process is running. It has support for the full task lifecycle (e.g. through the optional attributes create-tasks and end-tasks), including the 'blocking' semantics.
- start-state: for the sole purpose of being able to start a process by means of a human task. And therefore, blocking this makes no sense.
Take a closer look at the unit test that is shown in the thread you referred to, and you'll see that in the test that has a task in its start-state, the process is started through a createStartTaskInstance() - taskInstance.end() sequence, before the token ends up waiting in the 'going steady' state.
Your unit test starts the process in a different way (through the signal() call on the ProcessInstance). While this is still possible (i.e. having a task in the start-state doesn't prevent you from starting the process in another manner), it also means that in this case that task has no use anymore for this particular instance of the process, and therefore it is ignored completely.
So if you set out to have a blocking task as the first thing in your process, you need to do so with a task-node that directly follows your start-state. And actually, that's pretty much what you've done in your second unit test - but you just as well may omit your not-so-blocking task from the process definition. ;)
Regards,
Maurice