Closed sub-issues count against the 100-per-parent cap, so long-lived epics lose their open children

[glennsc]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Issues

Body

I hit this limit yesterday experimenting with migrating a 2,478-issue tracker into GitHub Issues, and I think the problem is bigger than "unlink some sub-issues."

One epic in that tracker has 451 children. 433 of them are closed. 18 are open. GitHub let me attach the first 100 and refused the rest:

Failed to add sub-issue #2645 to parent #2118. Parent cannot have more than 100 sub-issues (addSubIssue)

Because closed sub-issues count against the cap, the 18 open ones are the ones that lost their parent. That is backwards. The closed children are the history of the epic; the open ones are the work.

The suggested workarounds are hard to apply to a long-lived epic. Unlinking closed children throws away the record of what the epic contained. Splitting the epic into "Part 2" and "Part 3" invents an incorrect structure.

Any epic with very active work will reach this. A sub-issue list is exactly where closed items should be able to pile up without consequence.

Two changes would fix it, either one would do:

1. Don't count closed sub-issues against the limit.
2. Raise the limit substantially and page the list in the UI and API, the way every other list on GitHub already works.

Happy to share the tracker's numbers or the migration tool's output if it helps.

@rileybroughten @evi-liu

Guidelines

• I have read the above statement and can confirm my post is relevant to the GitHub feature areas Issues and/or Projects.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[TongyiDai]

The 451-child example shows why this is not merely a request for a higher arbitrary limit. GitHub documents a hard maximum of 100 sub-issues per parent, and the API rejection confirms that closed and open children share the same capacity. That makes the relationship unsuitable as a durable epic history once work exceeds the cap.

I would preserve two independent product requirements here:

• History-preserving capacity: closed children remain attached and auditable without consuming the parent's active-work budget.
• Scalable retrieval: UI and API paginate all children and expose open/closed counts and filters, rather than requiring clients to invent Part 2 parents.

A backwards-compatible design could keep the existing 100-open-child safety limit while allowing a paginated closed archive, or simply raise the total limit with cursor pagination. Until GitHub changes it, a migration tool should preflight child counts and avoid silently attaching the first 100; emit an explicit mapping report for every orphaned relationship.

[curtisholtt]

Additionally, there's a related UX gap in how the parent-child relationship displays.

For a child issue, the parent correctly shows in the right-hand sidebar, under "Relationships" — easy to find, consistent with everything else about the issue (Assignees, Labels, Projects, etc.).

For a parent issue, there's no equivalent. Its children only appear in the "Sub-issues" checklist embedded in the main body, directly below the description. On issues with long descriptions, that checklist gets pushed far down the page and becomes hard to find — you have to scroll past all the description content first.

It would help if the parent's sidebar showed a compact sub-issues summary in a fixed, predictable location (similar to how "Parent issue" shows for children), rather than relying entirely on body position. Right now, finding a parent's children means scrolling past its description every time, and that gets worse the longer the description is.

[selomrani]

yes

[glennsc]

These are good suggestions but focus on the prize: no arbitrary 100-subissue limit 🥇

It's hard to know if Github is still committed to going hard on Issues and Projects -- especially making it super fast and scalable. I wish they would. Such a natural place to plan and orchestrate your work.

[curtisholtt]

These are good suggestions but focus on the prize: no arbitrary 100-subissue limit 🥇

It's hard to know if Github is still committed to going hard on Issues and Projects -- especially making it super fast and scalable. I wish they would. Such a natural place to plan and orchestrate your work.

Facts, decades of usage and others just don't play well or work efficiently with other systems. Gitlab was close, but "big players" don't have sustainable workflows and connectivity, IMO. Hope they're reading, some of these are easy fixes...