Why are non-permitted transitions allowed?

[mfdewit]

Hi,
I'm trying to build a workflow in Nflow (version 9.0.0) and I have a problem with state transitions.
It appears that I can switch to any state, totally ignoring the permitted transitions.

So imagine 3 states:

• A (start)
• B (manual)
• C (normal)

And these transitions:

• permit A to B
• permit B to C

In the A method the returned NextState is B since this is how I want it to behave, but if I change it to return C this also works. In the logs I see a warning mentioning the state transition is not allowed. But looking at the actual state of of the instance in Nflow explorer it has transitioned anyway.

This also happens when doing manual updates using the API. When I transition it to B, it is waiting for the state to be updated using the REST API (or via a Java code). Using Nflow explorer I can set the state to C which is permitted, but I can also set it to A while this should not be possible. I don't even see a warning in the logs.

Am I missing something here?

[RealZimboGuy]

have you looked at this parameter

nflow.illegal.state.change.action
(log) Action to take when executing a state change that has not been explicitly permitted for the workflow. Value can be "ignore" (do nothing), "log" (default, log a warning) or "fail" (move workflow instance to error state).

based on what you want, set this to "fail" ?

[mfdewit]

Thanks, your suggestion is working! Unfortunately the documentation is not very complete and this property is not documented. But I've checked out the code now and this provides some useful insights.

Anyway, this property only 'guards' automatic transitions and moves the WF to error. This is what I expect. But using the API I can still move to any state, despite not being permitted.
I'm expecting it to ignore the call and leave the WF unchanged. But I'll see if I can find this in the code.

[mfdewit]

Yeah, I was just figuring out that from a management perspective it could be very useful to be able to force it into any state; just like you mentioned.

But then the next question rises; what is the desired and safe way of updating a WF that is waiting in a manual state?
Using the REST API is tricky, since the transitions are not checked and looking at the code (in WorkflowInstanceService.updateWorkflowInstance) the same applies to the Java API.

[RealZimboGuy]

this snipit of hacked together code which might be helpful, in java to query for a workflow instance and then change its state, you can just add filters to the search or filter it after the fact with some "ifs" on instance.state.equals("something")

	QueryWorkflowInstances query =
			new QueryWorkflowInstances.Builder()
					.addStatuses(WorkflowInstance.WorkflowInstanceStatus.inProgress,
							WorkflowInstance.WorkflowInstanceStatus.manual,
							WorkflowInstance.WorkflowInstanceStatus.executing)
                    .addTypes(MyWorkFlow.TYPE)
					.setIncludeCurrentStateVariables(true)
					.setBusinessKey(msisdn)
					.build();
	Collection<WorkflowInstance> instances = workflowInstances.listWorkflowInstances(query);


		for (WorkflowInstance instance : instances) {

			WorkflowInstance.Builder builder = workflowInstanceFactory.newWorkflowInstanceBuilder().setId(instance.id)
					.setNextActivation(now());
			builder.setState(UserMenuFlow.USER_INPUT.name());
			builder.putStateVariable("USER_INPUT", content);

			instance = builder.build();
			instance.getChangedStateVariables().forEach(workflowInstanceDao::checkStateVariableValueLength);
			WorkflowInstanceAction action = new WorkflowInstanceAction.Builder(instance)
					.setType(externalChange)
					.setStateText(content)
					.setExecutionEnd(now())
					.build();
			workflowInstances.updateWorkflowInstance(instance, action);

			//only let the first one process the input
			return;
		}

[mfdewit]

Thanks, I'll give this a try. In the mean time, I'm very interested in the view from the developers on the subject :)

[efonsell]

(nflow.illegal.state.change.action is documented here)

Indeed, setting any workflow state (from state methods and via APIs) is intentionally allowed, as it may be needed in some cases. nflow.illegal.state.change.action is not currently checked when the state change is made via APIs. It could be added though.

We could also consider adding support to control this on request level, possibly by adding a parameter like expectedStates in WorkflowInstanceService.wakeupWorkflowInstance, or actionOnIllegalStateChange similar to nflow.illegal.state.change.action with additional option to deny the change. Please create an issue if you think this sounds like a good idea and would solve your problem.

For now, I think you need to implement this check yourself, e.g. use WorkflowDefinition.isAllowedNextAction(...) to check if the state change is allowed or not before calling nFlow APIs. It should be reasonably safe, as the nFlow engine is not processing any instances in manual state, so the current state should not change between the check and the update.

[mfdewit]

Thanks for your reply!. In case we see a need for this we'll definitely create an issue. But first we need to get some more hands on experience.