This simplified design works just fine:

Hi @JohnieBraaf, thanks for reporting this. Does it mean that the simplified version is something you can go with?

Regardless, I will look into the first flow and try to reproduce it as soon as possible.

Hi @javrasya, yes for now I have worked around this issue by using the second workflow.
If I have time, I will create a demo project over the weekend to demonstrate the issue.

I have not yet found the time to create a sample project. But I do suspect this piece of code to be the culprit:

https://github.com/javrasya/django-river/blob/master/river/core/instanceworkflowobject.py#L57-L59

@javrasya, it seems that you are initializing the complete workflow upon creation of an workflow instance object.
Why not choose for the option of instantiating only the next available transitions/approvals and repeat after each approve?

I'm measuring database read/write and those are huge. Like about 100 per single case creation.
I have created a workaround for this as described above. Please let me know your thoughts and if I need to consider an PR.

I have created a commit that:

• creates only 1 iteration of future approvals. this eliminates the issue of re-cycling, so that code gets obsoleted
• some performance optimizations aimed at reducing the number of database calls

JohnieBraaf@84159da
must be used together with
JohnieBraaf@0d0db85

These changes alone slashed the total number of database operations in half. But still there are a lot of database calls going on.

@javrasya, it seems that you are initializing the complete workflow upon creation of an workflow instance object.
Why not choose for the option of instantiating only the next available transitions/approvals and repeat after each approve?

I'm measuring database read/write and those are huge. Like about 100 per single case creation.
I have created a workaround for this as described above. Please let me know your thoughts and if I need to consider an PR.

Hi @JohnieBraaf , thanks for giving a thought to this. The thing with that is that it allows customizing the workflow for a specific object. So it is like that by design. I don't think we should change the behavior unless it still supports this.

The only way to make django-river work that way would be to introduce something like overriding rules as part of the workflow which I have been thinking about but never had the time to invest in that. Then you use a workflow template and never have to re-create the entire workflow on and on but customize it for a specific object by defining overriding rules.

You don't need a full-fledged project to re-produce it btw. Here is an example of reproducing a scenario in a human-readable cucumber test;

72cdd6d

Thanks for your reply and pointers on creating the test scenario for this.

I do not fully understand what you mean with the current design allowing customization of a a specific object. The proposed solution increases flexibility and allows for ad-hoc workflow changes, I guess that you try to achieve the opposite.

Facing the same issue, I have the following patterns:

Reviewing -> Reverted -> Reviewing -> Reverted...

The Reverted state after 1 round of circulation was disappeared in Available Approvals list