GitHub REST API Bug: Cross-Repository Sub-Issues Undercounted, Impacting Developer Dashboards

GitHub REST API Bug Undermines Cross-Repository Issue Tracking

A recent discussion on GitHub's community forum has brought to light a critical bug impacting how sub-issues are counted across different repositories within an organization. This issue, reported by YarAllex, directly affects the accuracy of developer dashboard views and the reliability of git metrics related to project progress, especially for complex features spanning multiple teams or services.

The core of the problem lies with the GitHub REST API field sub_issues_summary.total. While GraphQL's subIssues.totalCount consistently provides the correct number of linked sub-issues, the REST API's counterpart frequently undercounts them, specifically dropping sub-issues that reside in different repositories. This discrepancy leads to an inaccurate representation of project completion and overall workload.

The Problem: Asynchronous Recounts Drop Cross-Repo Sub-Issues

YarAllex detailed a setup involving a parent issue in org/repo-a linked to a sub-issue in the same repository (org/repo-a#A) and another in a different repository (org/repo-b#B). While GraphQL correctly reports two sub-issues, the REST API's sub_issues_summary.total field incorrectly shows only one. This happens because, although the count is initially correct right after a linking mutation, a server-side asynchronous recount process silently excludes the cross-repository sub-issue(s).

Consider the expected versus actual REST API responses:

// Expected GET /repos/org/repo-a/issues/PARENT
"sub_issues_summary": {
  "total": 2,
  "completed": 1,
  "percent_completed": 50
}

// Actual GET /repos/org/repo-a/issues/PARENT
"sub_issues_summary": {
  "total": 1,
  "completed": 1,
  "percent_completed": 100
}

Key Evidence: The Reproduction Probe

The most compelling evidence comes from a reproduction probe where a temporary, same-repo sub-issue was added:

1. A POST request to link a dummy sub-issue in the same repository:

   POST /repos/org/repo-a/issues/PARENT/sub_issues

   The immediate response correctly showed "total": 3 (original same-repo + cross-repo + dummy).

2. However, after a short delay (approximately 2 seconds), a subsequent GET request to the parent issue returned:

   GET /repos/org/repo-a/issues/PARENT
   "sub_issues_summary": {
     "total": 1,
     "completed": 1,
     "percent_completed": 100
   }

   This clearly demonstrates that the asynchronous recount process not only drops the cross-repository sub-issue but also the recently added same-repository dummy sub-issue, leading to a significantly undercounted total.

Impact on Project Management and Monitoring Tools

The implications of this bug are substantial. Project boards that rely on the sub_issues_summary field for progress tracking (e.g., 'X / Y' completion on parent rows) will display incorrect information. Any git monitoring tool or custom integration that consumes this REST API endpoint will provide misleading git metrics, hindering accurate project oversight and resource allocation. This is particularly problematic for organizations that structure their projects with features spanning across dedicated backend and frontend repositories, a common pattern in modern development workflows.

Attempts at workarounds, such as re-linking sub-issues via REST or GraphQL, provide only momentary fixes before the asynchronous recount reverts the total to the incorrect value. Adding to the frustration, the bug appears non-deterministic, with some identically structured parent issues reporting correct counts while others do not.

YarAllex has filed a ticket with GitHub Support and shared this issue with the community to see if others are experiencing similar problems or have found a persistent solution. As of now, the community discussion primarily serves as an acknowledgment of the feedback by GitHub's automated system, highlighting the ongoing search for a resolution to this critical data inconsistency.