HTTP workflow Actions not executed after upgrade to 4.7

Hey everyone,

I updated to 4.7 today but realized that my http workflow actions are no longer executed since the upgrade. The workflows transition just fine and I don’t see any errors in the workflow actions nor in the logs in general. Is anyone else experiencing this? I already recreated the workflow actions without success.

Regards,
Thomas

Looking into this, setting up a lab for testing.

1 Like

I just found the problem on my end, sorry…

Until the 4.7 release I used the following template in the action url to access the workflow instance: {{ entry_log.workflow_instance }}

This does no longer work in 4.7, {{ workflow_instance }} works fine though. I did not find any related change in the release notes and did not receive any errors with {{ entry_log.workflow_instance }} though. It would be really helpful to get some kind of feedback when requests cannot be made at all due to an invalid template. Sorry for bringing this up but maybe somebody else will find this useful in the future.

1 Like

Since version 4.5 the context of the workflow is being updated incrementally into namespaces to avoid context clutter.

https://docs.mayan-edms.com/releases/4.5.html#id9

I can’t find the exact commit where entry_log was removed from the state action context. My guess is that this variable was regarded as internal/private to the workflow instance and not meant for user access.

I’ll audit the commits of the workflow for the past releases to determine if this was the correct course of action to move forward or revert it and add the removal as a breaking change if the code is not reverted.

{{ workflow_instance }} is meant to be the sole entry point to access workflow running context.

I can see the use case to pass the current entry log to the state action but in any case it will just be a shortcut to {{ workflow_instance.get_last_log_entry }}.

This seems to be the relevant commit:

before:

After:

According to the discussion notes:

  • State action execution code was duplicated at the state and workflow template levels.
  • The state action execution was to be unified.
  • The state action execution must be a state code, the workflow template or workflow instance must neither have direct knowledge of the state action models or manipulate them. That responsibility is now delegated to the state model.

The commit does not explicitly removes access to entry_log, it was just a side effect of the clean up and making the core correct. The entry_log variable was being passed to the state action by the workflow instance itself which violated the scope of manipulation.

Since the state is now responsible to the set the action context, we’ll discuss the option of adding the current workflow instance executed transition (entry_log) to the action context.