crodrigoquero
commented
3 years ago Problem solved.
Workflow states will work as expected independently of its order on the workflow chain.
So,, if any other previous workflow state CREATES A NEW CATEGORY during its execution, the current workflow state will restart automatically in order to setup the necessary directory and file watchers.
Also, if any other previous workflow state DELETES A GIVEN CATEGORY during its execution, the current workflow state will restart automatically in order to remove unnecessary directory / file watchers.
FYR, each file / folder watcher has an event handlers associated to it. The system is pretty optimized to consider only the changes in the workflow file system that are releveant for it, i.e. the changes produced by previous workflow states.
I have carried out all sort of testings, so now I'm pretty sure everything is working as it was originally planned.
I have added a new class to help in the workflow directories monitoring, and I also refactorized the worker code, which now is simpler and clean.
I have removed some unnecesary files by adding a .gitignore file.
I still have to carry out some refactoring, in order to implement better functional segregation and reusability, but for now its works!
Once in a workflow chain the nodes will work ok until 3th. step or sate. Once there, they will point to the inbox of the 1st state, so the categorization will start again from there.
Expected behavior
Current behavior
The fiinal state show in this image will never happen; the 3th ste will create categorization directories from the 1st ste output directories.
Conext
The 3th Main System Characteristic promise that The Workflow nodes are movable but it seems such a promise is not fulfilled.