GitHub Advisory Database GraphQL pagination - the agent only pulled the first 100 advisories and missed the new GHSA...

GitHub Advisory GraphQL pagination missed the new GHSA batch

TL;DR

Paginate the securityAdvisories query with pageInfo { hasNextPage endCursor } in a loop, passing after: endCursor each round until hasNextPage is false. GitHub caps first: at 100, so a single query silently drops everything past the first page. Looping to the end is the only complete pull, and it is a five-line change.

The failure

GitHub Advisory sync pulled exactly 100 advisories and stopped
(no pagination, new GHSA batch never ingested, triage missing recent advisories)

Steps

1. Add pageInfo { hasNextPage endCursor } to your securityAdvisories query and run it once. Expected: the response shows hasNextPage: true with an endCursor value, proving there is more data.

1. Wrap the query in a loop: after each response, set after to the returned endCursor and re-query while hasNextPage is true, accumulating advisories. Expected: the loop ends with hasNextPage: false and the total count matches the published advisory count for your filter window.

1. Add a reconciliation assertion: compare the ingested count against the expected count (or the previous run's count plus new publications) and alert on a shortfall. Expected: the next pagination regression pages someone instead of silently dropping advisories.

1. Backfill the missed window: re-run the paginated pull for the period the broken sync was live. Expected: the missing GHSA batch appears in triage.

Use this when

• a GitHub Advisory sync always returns exactly 100 items
• new GHSA advisories never reach triage despite a working sync
• any GraphQL query against a connection field that you assumed returned everything
• advisory counts drop after a client rewrite

Not for this skill when

• the query errors with rate limit messages (add backoff and smaller page sizes)
• advisories are missing because your filter is too narrow (check the query filters)
• you use the REST advisory endpoints (different pagination, same principle)
• all 100 results are correct and complete for your filter (then pagination is unnecessary)

Variant phrasings

• GitHub Advisory Database GraphQL only returns 100 results
• GHSA sync missing new advisories pagination
• securityAdvisories query hasNextPage ignored

Why it happens

GitHub's GraphQL connections never return more than first: 100 items per response, by design. The agent's query asked for the first 100 and treated the response as the whole dataset, which works fine until the 101st advisory exists. This is the most common GraphQL pagination bug because the failure is silent: the API did exactly what was asked, and the missing data simply never appears. Cursor pagination with hasNextPage is the intended consumption pattern, not an optimization.

Edge cases

• Large first: values burn rate limit faster. 100 per page is fine; do not try to dodge pagination with bigger pages.
• The advisory list changes while you paginate. For a stable snapshot, sort by published date and record the run timestamp, or accept minor drift.
• endCursor is opaque. Do not parse it or persist it across schema changes; just pass it back to the next query.
• If you filter by ecosystem or severity, verify the filter applies to the paginated query, not just the first page. A filter dropped from the loop query silently re-broadens the pull.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstsLEBifOmKydaRimsl8MJQ