> For the complete documentation index, see [llms.txt](https://docs.aviator.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aviator.co/mergequeue/concepts/pending-workflow-runs.md).

# Pending Workflow Runs

Learn how to hold a PR out of the queue until GitHub has started the CI runs for its latest commit, so the queue does not admit a PR GitHub will refuse to merge.

GitHub decides whether a required check is satisfied by looking at the workflow run currently responsible for it. A workflow run exists before the check runs it will report do, and in that window GitHub treats those checks as missing and refuses to merge the pull request.

Normally that window lasts a second or two and nobody notices. It becomes a problem when CI is re-triggered by events that do not change the commit. If a workflow lists `labeled`, `unlabeled` or `edited` under its `pull_request` trigger, then adding a label starts a fresh run on a commit whose code is unchanged. Aviator still holds the previous run's results, which are green, so it admits the pull request. GitHub then declines the merge because the new run has not reported yet.

That produces a loop that is hard to read from the PR page: Aviator queues the PR, GitHub refuses, Aviator marks the PR stuck and adds a label, and the label change starts CI again.

Enabling `wait_for_pending_github_workflows` closes the window. Aviator holds the pull request out of the queue while GitHub has a workflow run for the head commit that has not started, and admits it once the runs are reporting.

## Configuration

This property lives under `merge_rules.merge_mode.parallel_mode` in your Aviator configuration file.

### `wait_for_pending_github_workflows`

Hold a pull request out of the queue while GitHub has a workflow run for its latest commit that has not started yet.

| Property | Value   |
| -------- | ------- |
| Type     | boolean |
| Default  | `false` |

```yaml
merge_rules:
  labels:
    trigger: "mergequeue"
  merge_mode:
    type: "parallel"
    parallel_mode:
      wait_for_pending_github_workflows: true
```

## When to enable it

Enable it if your workflows re-run on events that do not change the commit. The clearest signal is a `pull_request` trigger that includes `labeled`, `unlabeled` or `edited`:

```yaml
on:
  pull_request:
    types: [opened, synchronize, labeled, unlabeled]
```

If those triggers are not needed, removing them is the better fix, and it is the one that removes the underlying churn rather than working around it. A label change cannot alter what your CI would test, so re-running on it costs CI capacity and creates the window this setting exists to cover. `synchronize` already covers real code changes.

Leave the setting off if your workflows only run on pushes. It has no effect there, since the runs from the original push have long since reported.

## While a pull request is held

The pull request stays out of the queue and its Aviator status reads `waiting for GitHub to start the CI runs for the latest commit`. The [sticky comment](/mergequeue/concepts/sticky-comments.md) names the workflows that have not started, so you can find them on the repository's Actions tab.

Aviator re-checks on its own and queues the pull request as soon as the runs start reporting. No action is needed.

A run that never starts does not hold a pull request forever. Aviator stops waiting on a run after an hour and lets the pull request through, on the grounds that a run which has not started by then is stuck rather than slow. Self-hosted installations can change that limit with the `PENDING_GITHUB_WORKFLOW_MAX_WAIT_MINS` environment variable.

## Limitations

* Available in parallel mode only.
* Applies to GitHub Actions workflow runs. CI providers that report through other means are not covered.
* Aviator does not distinguish runs that feed a required check from those that do not, so a workflow that is slow to start delays queueing even when its checks are not required. This is bounded by the maximum wait described above.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.aviator.co/mergequeue/concepts/pending-workflow-runs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.