Do you have a sample query to start from? I’m not sure where the problem is from your description.

Thanks.

Whoops, really sorry about the late reply, I thought I’d get a notification on github 

So say I wanted to query issues by looking at the repo owner, and the name - this is V4 of the API

query get20Issues($owner: String!, $name: String!, $cursor: String) {
    repository(owner: $owner, name: $name) {
      issues(
        first: 20
        after: $cursor
        orderBy: { field: CREATED_AT, direction: DESC }
      ) {
        nodes {
          number
          body: bodyText
          title
          state
          labels(first: 5) {
            nodes {
              name
              color
            }
          }
        }
        pageInfo {
          endCursor
        }
      }
    }
  }

What it returns is an array of issue nodes … all fine and good, but what it lacks is that issues are separate from pull-requests … I’m guessing that’s the design decision, but it’s different from that of V3, where each issue object returned had a pull_request key, signifying that this issue is also a pull request.

However, that means for V4 we would have to query for both issues and pull-requests keep the pageInfo  for both … 

query getNIssuePr($owner: String!, $name: String!, $issue_cursor: String, $pr_cursor: String, $num:Int) {
    repository(owner: $owner, name: $name) {
      issues(
        first: $num
        after: $issue_cursor
        orderBy: { field: CREATED_AT, direction: DESC }
      ) {
        nodes {
          number
          ...
          labels(first: 5) {
            nodes {
              name
              color
            }
          }
        }
        pageInfo {
          endCursor
        }
      }
      pullRequests(
        first: $num
        after: $pr_cursor
        orderBy: { field: CREATED_AT, direction: DESC }
      ) {
        nodes {
          number
...
          labels(first: 5) {
            nodes {
              name
              color
            }
          }
        }
        pageInfo {
          endCursor
        }
      }
    }
  }

Which will give us 20 of the most recent of both issues and PRs

Now if we were to call V3, then we’ll go ahead and grab the most recent 40 issues - SOME of them PR, but not 50% always, but they’ll always be the most recent 40 issues/PR, and we can tell via the  pull_request key.

Going back to V4, the particular repo might have the most recent 30 issues be normal issues, and 31-50 being PRs, by my 2nd snippet, we’ll be grabbing 0-19 as issue, then 31-50 as PR, skipping 20-29

So I was wondering if I could do the same thing as api V3 in api V4

Thanks!

There isn’t a connection that offers pagination, but there is the issueOrPullRequest field that allows you to query by number. So you could get the latest issue and the latest pull request, pick the higher number and then count backwards from there to get the latest 40 issues or pull requests.

I hope that helps.

Please pardon my inexperience, so that would mean, I’d have to to multiple queries then?

1. Grab latest number from issue or PR

2. a forEach loop calling with the latest number to a certain length, if 20 that would mean 20 individual queries?

I ws hoping to use something like issueOrPullRequest(range of number)

Is that acceptable for graphQL? I was under the impression less queries were the best thing…

Mhm… I tried quite a bit to see what I can do to use the least amount of queries - but to no avail.

I’m guessing Github just decided to separate issues from pull requests for good in v4 to minimize extra data from coming in?

And thanks for your answers and patience!