Reopened pull request triggers multiple workflows

Hello, community

I’ve noticed quite strange behaviour of workflows when pull request is closed and reopened, and commit was made to the feature branch during the time PR was closed.

So, the configuration of triggers is following:

      - master

And here is the sequence of actions a developer makes:

  1. Create feature branch from master
  2. Create a PR: feature -> master (activity type - opened, workflow is triggered)
  3. Update feature branch (activity type - synchronize, workflow is triggered)
  4. Close PR, without removing feature branch (nothing happens, expected)
  5. Push to feature branch (nothing happens, expected)
  6. Reopen PR (2 workflows are triggered - for reopened and synchronize activity types)

Default activity types for pull_request event are: opened, synchronize and reopened. Also, no workflows are associated with push event for feature branch. So, behaviour of items 1 - 5 seems correct.

But I’m not sure I understand why 2 workflows are triggered almost simoultaneously when PR is reopened and push to feature branch was made during the time it was closed.
Also, here are the things that make it even more confusing:

  1. Both workflows show same SHA’s
  2. Event though they are triggered almost simoultaneously, the exact order is different - sometimes is reopened then synchronize, but sometimes it’s vice versa.

I would really appreciate is somebody could:

  • clarify if it’s designed to be like that
  • help to find a workaround (if yes)
  • tell if a fix is planned (if no)

Forgot to mention what problems such behaviour creates.

  1. In our case each workflow, that is triggered by pull request events, is supposed to run a deployment, and one of its steps executes Terraform. So we have some kind of race condition here, when one of the workflows fails because it can’t aquire lock (we have S3 + DynamoDB as backend).
  2. One of the last steps executes Helm, so probably it also won’t be a perfect solution to trigger 2 Helm deployments within a couple of seconds.
1 Like


Thanks for your feedback.
To avoid triggering 2 workflow runs simultaneously when you reopen the PR, currently you can remove the activity type reopened from the pull_request event in your workflow file.

    types: [opened, synchronize]
      - master

About your request to explain and change this phenomenon, I have created an internal ticket to report these questions to the appropriate engineering team for further evaluation and discussion. If they have any progress, I will notify you in time, and sometimes the appropriate engineers may directly reply you here.

@brightran, thanks for the advice.
Currently I can’t exclude reopened from activity types, so probably will just tell users to avoid commits while PR is closed.
Looking forward for the updates from engineering team.


I have got the reply from the engineering team, and their suggestion is same as mine that removing the activity type reopened from the pull_request event in your workflow file.

If you can’t exclude reopened, as you mentioned, you need to avoid pushing new commits to the source branch during the PR is closed without merged.

Hi @brightran
Thanks for the feedback!

Is it expected that now reopened and synchronize workflows have different SHA?

Reopened workflow now has previous commit SHA.
Synchronize workflow now has latest commit SHA.

When I created this topic and simulated described scenario, SHA of both workflows were same.