Summary
github.list_repository_issues fetches one GitHub page and then filters pull requests out of it:
https://github.com/oomol-lab/open-connector/blob/v1.3.1/src/providers/github/runtime-issue.ts#L275-L293
return {
issues: issues.filter((issue) => issue.pull_request == null),
};The response exposes only the filtered array, which destroys the only pagination signal a page-number caller has — the raw page length. GitHub's /issues endpoint mixes issues and pull requests, so for a caller requesting perPage: 100:
- a short
issues array may be a final page or a full raw page with PRs mixed in;
- an empty
issues array may be the true end or a raw page of 100 consecutive PRs (entirely realistic on PR-heavy repositories, where merge traffic dominates).
No termination rule computable from the filtered response is sound: stop-on-short truncates on the first page containing a PR; stop-on-empty truncates on any all-PR page; probe-K-more is defeated by K+1 consecutive all-PR pages. Any paginating consumer therefore either silently drops every issue after the first PR-bearing page or can never terminate. The input schema offers no flag to disable the filtering, so this cannot be worked around from the caller side.
Proposal
Keep the PR filtering (it's a documented, useful behavior) but restore the lost signal: report the raw page length alongside the filtered rows, e.g.
{ "issues": [ ... ], "pageInfo": { "fetched": 100 } }declared in the action's outputSchema, with the pagination rule stated in the action description: continue while fetched equals the requested page size, even when issues comes back short or empty.
Context
Found while integrating this action into Skardi's Open Connector source packs, where page-number pagination over the action is driven mechanically — but the failure mode applies to any paginating consumer, including agents following the agent.md guide.
Summary
github.list_repository_issuesfetches one GitHub page and then filters pull requests out of it:https://github.com/oomol-lab/open-connector/blob/v1.3.1/src/providers/github/runtime-issue.ts#L275-L293
The response exposes only the filtered array, which destroys the only pagination signal a page-number caller has — the raw page length. GitHub's
/issuesendpoint mixes issues and pull requests, so for a caller requestingperPage: 100:issuesarray may be a final page or a full raw page with PRs mixed in;issuesarray may be the true end or a raw page of 100 consecutive PRs (entirely realistic on PR-heavy repositories, where merge traffic dominates).No termination rule computable from the filtered response is sound: stop-on-short truncates on the first page containing a PR; stop-on-empty truncates on any all-PR page; probe-K-more is defeated by K+1 consecutive all-PR pages. Any paginating consumer therefore either silently drops every issue after the first PR-bearing page or can never terminate. The input schema offers no flag to disable the filtering, so this cannot be worked around from the caller side.
Proposal
Keep the PR filtering (it's a documented, useful behavior) but restore the lost signal: report the raw page length alongside the filtered rows, e.g.
{ "issues": [ ... ], "pageInfo": { "fetched": 100 } }declared in the action's
outputSchema, with the pagination rule stated in the action description: continue whilefetchedequals the requested page size, even whenissuescomes back short or empty.Context
Found while integrating this action into Skardi's Open Connector source packs, where page-number pagination over the action is driven mechanically — but the failure mode applies to any paginating consumer, including agents following the agent.md guide.