feat(github): paginate flare_git list actions instead of truncating at 30

[devin-ai-integration]

Summary

Follow-up to the #221 review. The flare_git list actions (pr_list, issue_list, release_list, run_list) hit GitHub's list endpoints with no per_page/pagination, so they silently returned only the first 30 items — on a busy repo the tail is dropped with no indication.

This adds a single pagination helper on the client and routes the four list endpoints through it:

// src/github/client.rs
const PER_PAGE: usize = 100;

pub fn get_paginated(
    &self,
    base_path: &str,
    extract: impl Fn(&Value) -> Vec<Value>,   // identity for bare arrays, envelope key for wrapped
) -> Result<Value, GitHubError> {
    // walks ?page=1..N&per_page=100, stops on the first short page,
    // returns the concatenated items as one JSON array
}

• pulls::list, issues::list, releases::list → bare-array endpoints, use the shared client::as_array extractor.
• actions::list_runs → { "workflow_runs": [...] } envelope, uses a local workflow_runs extractor. (parse_runs was replaced by that extractor; its two tests were updated in place.)

Query strings already present on the path (e.g. ?state=open, ?branch=x) are preserved — the helper picks ? vs & based on whether the base path already contains a query.

Test plan

• cargo test --workspace (27 github tests pass, incl. new as_array_* / workflow_runs_*)
• cargo clippy --locked --workspace --all-targets --all-features -- -D warnings -A unsafe_code -A clippy::pedantic
• cargo fmt --check

Notes for reviewers

• Risk areas / edge cases: stop condition is "page shorter than PER_PAGE"; a run of exactly PER_PAGE items costs one extra request that returns empty, then stops — correct, just one extra round-trip. Non-array / missing-key responses degrade to an empty page (extractors default to vec![]), so a malformed page ends pagination rather than looping.
• Backwards compatibility: return types unchanged (Vec<PullRequest>, etc.); callers and MCP output formats are untouched. Behavior change is strictly "returns all items instead of the first 30".

Link to Devin session: https://app.devin.ai/sessions/1d454eb984eb4b71a45d2bd42793cb80
Requested by: @getappz

Summary by CodeRabbit

• New Features

  • Added support for retrieving complete paginated results from GitHub list endpoints.
  • Issue, pull request, release, and workflow-run listings now include results across all available pages.

• Bug Fixes

  • Prevented listings from being limited to the first page of GitHub results.
  • Improved handling of empty or unexpected response formats.

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[coderabbitai]

📝 Walkthrough

Walkthrough

GitHub list operations now use a shared pagination helper that aggregates pages into JSON arrays. Issues, pull requests, releases, and workflow runs were updated to use this flow, with workflow-run responses extracting the workflow_runs array before deserialization.

Changes

GitHub pagination

Layer / File(s)	Summary
Shared pagination helper src/github/client.rs	Adds PER_PAGE, Client::get_paginated, and as_array, with tests for bare-array extraction.
Paginated endpoint integration src/github/actions.rs, src/github/issues.rs, src/github/pulls.rs, src/github/releases.rs	Updates list operations to aggregate paginated results; workflow runs extract the workflow_runs array from each response before parsing.

Estimated code review effort: 2 (Simple) | ~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ListOperation
  participant Client
  participant GitHubAPI
  ListOperation->>Client: call get_paginated with path and extractor
  Client->>GitHubAPI: request each page
  GitHubAPI-->>Client: return page JSON
  Client->>Client: extract and aggregate items
  Client-->>ListOperation: return aggregated array

Loading

Possibly related PRs

• getappz/agentflare#221: Updates the same GitHub REST list operations to use Client::get_paginated and array extraction helpers.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and accurately summarizes the main change: adding pagination for GitHub list actions.
Description check	✅ Passed	The description matches the template and includes a summary, test plan, and reviewer notes with relevant details.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch devin/1784314608-flare-git-pagination

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

src/github/client.rs (1)

104-129: 📐 Maintainability & Code Quality | 🔵 Trivial | 🏗️ Heavy lift

Add an integration test for the pagination loop.

The current tests cover as_array only; they do not verify query preservation, page/per_page generation, multi-page aggregation, the 100-item boundary, or later-page error propagation. A mocked two-page response would cover the behavior introduced here.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/github/client.rs` around lines 104 - 129, Add an integration test for
GitHubClient::get_paginated using a mocked two-page endpoint: verify existing
query parameters are preserved, each request includes the expected per_page=100
and page values, exactly 100 items on the first page triggers a second request,
results from both pages are aggregated, and an error from a later page is
propagated.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/github/client.rs`:
- Around line 104-129: Add an integration test for GitHubClient::get_paginated
using a mocked two-page endpoint: verify existing query parameters are
preserved, each request includes the expected per_page=100 and page values,
exactly 100 items on the first page triggers a second request, results from both
pages are aggregated, and an error from a later page is propagated.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: c2c352f8-aaf3-49f0-802d-10b5fc8922b7

📥 Commits

Reviewing files that changed from the base of the PR and between a9d3095 and 54a9a15.

📒 Files selected for processing (5)

• src/github/actions.rs
• src/github/client.rs
• src/github/issues.rs
• src/github/pulls.rs
• src/github/releases.rs