GitHub Project Boards Bug: Sub-Issue Progress Counters Stuck, Impacting Software Development Measurement

A recent discussion in the GitHub Community has brought to light a significant regression impacting the utility of GitHub Project Boards for tracking nested tasks. Developers are reporting that the sub-issue progress counter for newly created Maintasks is displaying an incorrect value, often stuck at "0/1", despite sub-issues being correctly linked and visible elsewhere.

The Problem: Inaccurate Software Dashboard Metrics

The core issue, first reported by dentunc, describes a scenario where a new Maintask with multiple sub-issues shows "0/1 (0%)" in the Project Board's "Sub-issues progress" column. This directly impacts software development measurement, as teams rely on these counters for quick visual updates on epic or feature progress. Crucially, the issue detail page for the Maintask correctly displays the full count (e.g., "10/10"), and older Maintasks created before approximately April 16, 2026, continue to function as expected. This discrepancy points to a recent platform regression.

Community Confirmation and Deeper Analysis

Multiple community members quickly confirmed the bug. MatejHamala noted an additional symptom: newly created sub-issues appearing twice in the hierarchical view. SimonHellings and haoyan-ts corroborated the primary issue, with haoyan-ts specifically detailing how their private repo's older parent issues showed correct progress (4/4), while newer ones were stuck at 0/1, despite API calls (both REST and GraphQL) returning the correct sub-issue counts.

A thorough investigation by dfaivre-pcs provided critical technical insights:

• The issue isn't confined to the Project Board; the "0/1" badge also appears on the native issue list view.
• The broken field is identified as subIssuesSummary (GraphQL) or sub_issues_summary (REST). The underlying Issue.subIssues.totalCount remains accurate.
• The bug affects all sub-issue write paths (REST, GraphQL mutations, and extensions), indicating it's not specific to how sub-issues are created or linked.
• The entire summary object is frozen: closing children doesn't increment the .completed count, and even removing all children doesn't unstick the counter from its initial {total: 1, completed: 0} state.
• Interestingly, the mutation response itself returns the correct, live-computed value every time, suggesting the computation works, but the persistence of this recomputed value is failing after the initial transition.

Balamurugan7845 further hypothesized the cause as an "Aggregation/Synchronization Issue," rather than a linking problem. This suggests a desynchronization between the issue relationship data and the Project Board's aggregation layer, likely due to a recent backend change affecting sub-issue relationship aggregation, project field calculation logic, or cache invalidation.

Impact on Performance Measurement Metrics

For teams relying on GitHub Projects as their primary software dashboard, this regression significantly hinders their ability to gain at-a-glance insights into project health and epic completion. The inaccurate progress counters make it challenging to track large initiatives, potentially leading to misinformed decisions or increased manual overhead to verify progress, thereby impacting overall performance measurement metrics.

Workaround and Resolution

Fortunately, GitHub staff member nasquasha acknowledged the issue, stating that the cause has been identified and a fix is in progress. In the interim, a temporary workaround exists: changing the state of any of the sub-issues (e.g., closing and then re-opening it) should trigger an update to accurately reflect the progress. The problem specifically lies with adding/removing sub-issues, which is what the GitHub team is actively addressing.

This community discussion highlights the importance of active user feedback in identifying and resolving critical platform regressions that affect developer productivity and project visibility.