GitHub API Bug Hinders Software Engineering Performance Metrics for Workflow Runs

Reliable API interactions are the backbone of efficient software development, especially when it comes to automating workflows and gathering software engineering performance metrics. However, a recent and recurring issue in the GitHub REST API is causing significant headaches for developers, specifically impacting the ability to accurately filter GitHub Actions workflow runs by branch.

The Intermittent `branch` Filter Bug in GitHub's REST API

A critical discussion on the GitHub Community platform, initiated by user theyoprst, highlighted an intermittent but currently reproducible bug affecting the GET /repos/{owner}/{repo}/actions/runs and GET /repos/{owner}/{repo}/actions/workflows/{id}/runs endpoints. When attempting to filter workflow runs using the documented branch query parameter, the API intermittently returns total_count: 0 and an empty workflow_runs array, even when numerous runs exist for that branch.

This behavior forces developers to fetch unfiltered data—potentially thousands of entries—and perform client-side filtering, a process that is both inefficient and cumbersome. The issue is not new; similar bugs concerning filtering on workflow runs have been reported previously, notably #24626 (open since 2021) and #53266, suggesting a deeper, persistent problem within GitHub's API indexing or search mechanisms.

Reproducing the Issue

The original post provided clear steps to reproduce the bug, demonstrating its impact across various public repositories. The following curl command snippet, using a GitHub token, clearly illustrates the discrepancy:

TOKEN="$(gh auth token)"
for repo_branch in \
"nebius/soperator:main" \
"anthropics/claude-code:main" \
"cli/cli:trunk" \
"kubernetes/kubernetes:master" \
"actions/checkout:main"
do
repo="${repo_branch%:*}"; branch="${repo_branch#*:}"
base="https://api.github.com/repos/${repo}/actions/runs"
unfiltered=$(curl -s -H "Authorization: bearer $TOKEN" -H "Accept: application/vnd.github+json" "${base}?per_page=1" | jq -r '.total_count')
filtered=$(curl -s -H "Authorization: bearer $TOKEN" -H "Accept: application/vnd.github+json" "${base}?per_page=1&branch=${branch}" | jq -r '.total_count')
printf "%-30s branch=%-10s unfiltered=%-7s branch_filter=%s
" "$repo" "$branch" "$unfiltered" "$filtered"
done

The expected result is that branch_filter would show a non-zero subset of unfiltered runs. However, the actual output consistently shows branch_filter=0 across all tested repositories, despite the unfiltered count being in the thousands. This demonstrates a clear failure of the API's filtering mechanism.

Impact on Developer Productivity and CI/CD

This bug has significant implications for developer overview and the reliability of continuous integration and continuous deployment (CI/CD) pipelines. Many CI workflows depend on this specific API endpoint to identify the latest successful build on a particular branch. For example, a common pattern involves:

gh api -X GET "/repos/${REPO}/actions/workflows/${WF}/runs" \
-F branch="${BRANCH}" -F status=success -F per_page=1 \
--jq '.workflow_runs[0]'

When the branch filter fails, such queries return empty results, causing upstream jobs to exit prematurely and triggering cascading failures in downstream processes. This leads to wasted developer time spent debugging "ghost failures" in their own code, only to find the issue resolves itself minutes later due to the intermittent nature of the API bug. Such unpredictability severely hinders developer performance metrics and overall team efficiency.

A Note on Related Observations

During the investigation, it was also noted that the (undocumented) head_branch= parameter is silently ignored by the API, returning unfiltered results regardless of the value provided. While not directly related to the branch= bug, this adds to the confusion for developers attempting to find alternative filtering methods.

While the original discussion was unfortunately closed by a GitHub Actions bot for not adhering to a template, the underlying technical issue remains critical. It underscores the importance of robust and reliable API services for the smooth functioning of modern software development workflows.

Developers are currently left with the workaround of fetching all runs and filtering them client-side, awaiting a permanent fix from GitHub to restore confidence in this essential API functionality.