Is there a way to get all sub-issues from the API?

[doliveirakn]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

This is similar to this discussion: https://github.com/orgs/community/discussions/191833
However, the provided answer there does not work as expected.

In the GitHub UI, I can query for records that have a parent-issue and get a list of all of the sub-issues

However, when I provide the same search to the rest API such as:
https://api.github.com:443/search/issues?q=is:issue+state:open+has:parent-issue+repo:<repo name>
it will return all of the open issue regardless of if they have a parent issue or not.

I've also tried is:sub-issue, has:sub-issue but neither of these manage to filter to sub-issues.

I have found that no:parent-issue does return all of the non-subissues. However, I cannot get just a list of issues that ARE sub-issues.

Is there a way to to this at all using the REST API?

[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. ⭐

[ayoubodf-dev]

The issue-search endpoint and the UI/Projects filters do not currently expose the same hierarchy filters. In particular, has:parent-issue is not documented as a REST /search/issues qualifier, so relying on it can produce exactly this result: the qualifier is ignored and all otherwise matching issues are returned.

For a repository-wide list, GraphQL is the cleanest workaround because Issue.parent is available on each issue:

gh api graphql --paginate \
  -f owner=OWNER \
  -f repo=REPO \
  -f query='
    query($owner: String!, $repo: String!, $endCursor: String) {
      repository(owner: $owner, name: $repo) {
        issues(
          first: 100
          after: $endCursor
          states: OPEN
          orderBy: {field: CREATED_AT, direction: ASC}
        ) {
          pageInfo { hasNextPage endCursor }
          nodes {
            number
            title
            url
            parent {
              number
              url
              repository { nameWithOwner }
            }
          }
        }
      }
    }
  ' \
  --jq '.data.repository.issues.nodes[]
    | select(.parent != null)
    | {
        issue: .number,
        title,
        url,
        parent: ("\(.parent.repository.nameWithOwner)#\(.parent.number)")
      }'

That returns only open issues in OWNER/REPO that have a parent, including the parent repository when the relationship crosses repositories. Remove states: OPEN if you also need closed issues (or request both states).

REST now has dedicated sub-issue relation endpoints, including GET /repos/{owner}/{repo}/issues/{issue_number}/parent, but there is no single repository-wide REST endpoint that lists every issue having a parent. A REST-only implementation therefore has to list candidate issues and call /parent for each one, treating 200 as a sub-issue and 404 as no visible parent. GraphQL avoids that N+1 request pattern.

References:

• REST API endpoints for sub-issues
• GraphQL Issue fields

[doliveirakn]

For organizations with many issues, both options seems very inefficient. Even with a graphQL approach, needing to make an arbitrary number of requests in order to just get a full "Page" worth of data and, due to the way the cursor works, makes it so you can't even get a second page, without paging through all of the data again.

Really unfortunate that the filters exposed in the UI are not supported at all in the API

[ayoubodf-dev]

You are right, especially for an API that needs to expose its own stable pages. I should distinguish a one-time batch export from a genuinely server-side pageable query.

gh api graphql --paginate does carry the underlying endCursor forward during one invocation, so that single run does not reread earlier issue pages. However, select(.parent != null) is still client-side. Producing, for example, 100 matching sub-issues may require scanning an arbitrary number of ordinary issue pages. A service that returns a continuation token would also have to preserve the underlying GitHub cursor (and any already-fetched matching overflow) between requests. That is a workaround, not efficient server-side pagination over sub-issues.

As far as the documented REST and GraphQL schemas currently go, there is no repository-wide parent != null filter equivalent to the UI qualifier. GraphQL only reduces the REST N+1 relationship lookups; it does not solve the filtering/pagination limitation. For a large organization or interactive application, your feature request for API parity with the UI is therefore valid.