Concurrency policy only restricts executions in scheduled & running states

SUMMARY

Concurrency policies on an action ref only checks for existing executions in scheduled & running states before executing. Paused workflows should be considered as well.

The code that implements the concurrency policy is here

    def _apply_before(self, target):
        # Get the count of scheduled instances of the action.
        scheduled = action_access.LiveAction.count(
            action=target.action, status=action_constants.LIVEACTION_STATUS_SCHEDULED)

        # Get the count of running instances of the action.
        running = action_access.LiveAction.count(
            action=target.action, status=action_constants.LIVEACTION_STATUS_RUNNING)

        count = scheduled + running

        # Mark the execution as scheduled if threshold is not reached or delayed otherwise.

I propose that the count should be extended to include some/all of

• LIVEACTION_STATUS_REQUESTED
• LIVEACTION_STATUS_SCHEDULED
• LIVEACTION_STATUS_DELAYED
• LIVEACTION_STATUS_RUNNING
• LIVEACTION_STATUS_PENDING
• LIVEACTION_STATUS_PAUSING
• LIVEACTION_STATUS_PAUSED
• LIVEACTION_STATUS_RESUMING

Consider:

    def _apply_before(self, target):
        # Get the count of non-completed instances of the action.

        # could move this into st2common.constants.action
        valid_concurrent_statuses = [
            action_constants.LIVEACTION_STATUS_REQUESTED,
            action_constants.LIVEACTION_STATUS_SCHEDULED,
            action_constants.LIVEACTION_STATUS_DELAYED,
            action_constants.LIVEACTION_STATUS_RUNNING,
            action_constants.LIVEACTION_STATUS_PENDING,
            action_constants.LIVEACTION_STATUS_PAUSING,
            action_constants.LIVEACTION_STATUS_PAUSED,
            action_constants.LIVEACTION_STATUS_RESUMING,
        ]
        count = sum([action_access.LiveAction.count(action=target.action, status=s) for s in valid_concurrent_statuses])

        # Mark the execution as scheduled if threshold is not reached or delayed otherwise.

I'd be willing to create a PR for this if the st2 team agrees that this is the desired behavior of the concurrency policy.

STACKSTORM VERSION

root@76ffd0a933ef:/# st2 --version
st2 3.1.0, on Python 2.7.6

OS, environment, install method

Docker mppc

Steps to reproduce the problem

Create a concurreny policy on a workflow that has a step which pauses it, create an execution of the workflow and wait until it pauses, create another workflow execution.

Expected Results

The concurrency policy should prevent another execution, as it is possible for both workflows to then be unpaused and running at the same time, which would break the concurrency policy.

Actual Results

Both workflow executions are created.