state-machine: what do we mean with "processed"?

[ndr-brt]

Currently the functions that are executed by the state machines on every iteration return a boolean.
Those boolean are counted by ProcessorImpl:

Connector/core/common/state-machine/src/main/java/org/eclipse/edc/statemachine/ProcessorImpl.java

Lines 61 to 62 in 9d39f5c

	.filter(isEqual(true))
	.count();

and the count is used to decide whether to add a delay on the iteration or not:

Connector/core/common/state-machine/src/main/java/org/eclipse/edc/statemachine/StateMachineManager.java

Lines 108 to 114 in 9d39f5c

	var processed = processors.stream()
	.mapToLong(Processor::process)
	.sum();
	waitStrategy.success();
	var delay = processed == 0 ? waitStrategy.waitForMillis() : 0;

I discovered that there is no function that's returning false so we're not using that feature that, thinking about it, is not really necessary anyway because an entity that gets fetched is also supposed to be processed in a certain way.
So the logic should/could be:

• in every iteration:
  • if no entities are fetched (thus processed) apply waitStrategy
  • if one or more entities are fetched (thus processed), do not apply waitStrategy and start next iteration immediately.

This will simplify the process functions signature that often causes headache during the implementation (should I return true or false?).

Any thoughts on that?

[paullatzelsperger]

One thing to keep in mind is, that it is possible, that an entity gets fetched, because it's not leased, but no action can be performed on it.
Cases like this - if they exist - shouldn't contribute to the processed count, because it would put unnecessary load on the database.

[ndr-brt]

I don't think we should have cases where the action cannot be performed (and in fact we don't have them currently), because they will end up wasting state machine cycles.
The cases where the return false was used it were for not-optimal design choices, like the status checker.
Those kind of patterns, like a poll system that should work when an entity is in a specific state, should be implemented through an external component that could be a state machine as well (like how we did with the PolicyMonitor).

[paullatzelsperger]

my point exactly. if such cases don't exist, all the better.

[ndr-brt]

ok, I got your comment in the wrong way, all good! 🙌

[jimmarino]

ah good point