fix: pr-bug-scan validated finding from #4437

[buf0-bot]

Automated fix-PR from pr-bug-scan for parent #4437.

Fixer status: FIXED_WITH_CODE_PROOF
Summary: Cap GraphQL first at 50 per request and walk cursors to accumulate up to effectiveLimit, blocking Linear's 50-arg connection cap on Load more.
Blocked proof link: src/main/linear/issues.ts:338 variables = { first: effectiveLimit, orderBy } passed directly to ALL_ISSUES_QUERY/VIEWER_*_ISSUES_QUERY rawRequest with first=72/108/.../216
Typecheck: pass

Proof (from validator)

• C1 — proof_type: code_analysis
  • trigger: User clicks Load more on a connected Linear Issues tab (All/Assigned/Created/Completed). TaskPage increments linearIssueLimit by LINEAR_ITEM_LIMIT (36) to 72, then 108, …, capped at LINEAR_PLAIN_ISSUE_LIST_MAX (216).
  • observable: Either the rawRequest rejects (Linear's connection arg validation caps first at 50) and the catch at src/main/linear/issues.ts:386-396 returns { items: [], hasMore: false } — the visible list blanks out and the Load more button disappears; or Linear silently truncates to 50, in which case clicking Load more from 36 returns at most 50 rows (a single click of ≤14 new rows, then no more new rows on further clicks even with hasMore=true).
  • path:
    • src/renderer/src/components/TaskPage.tsx:3647 handleLoadMoreLinearIssues bumps linearIssueLimit by LINEAR_ITEM_LIMIT, capped at LINEAR_PLAIN_ISSUE_LIST_MAX=216
    • src/renderer/src/components/TaskPage.tsx:5338 effectiveLinearIssueLimit = clampLinearPlainIssueListLimit(linearIssueLimit) (max 216)
    • src/renderer/src/components/TaskPage.tsx:5384 listLinearIssues(readArgs.filter, effectiveLinearIssueLimit, ...)
    • src/renderer/src/store/slices/linear.ts:799 effectiveLimit = clampLinearPlainIssueListLimit(limit) — preserves 72/108/...
    • src/renderer/src/runtime/runtime-linear-client.ts:142 linearListIssues forwards limit (72/108/...) to runtime/IPC
    • src/main/runtime/orca-runtime.ts:12463 linearListIssues(... clampLinearPlainIssueListLimit(limit) ...) — passes through unchanged

Reproduction

pnpm vitest run --config config/vitest.config.ts src/main/linear/issues.test.ts

• before fix:
• after fix: 6 existing tests still pass; new pageSize is min(50, remaining) per rawRequest call, with cursor walk via pageInfo.endCursor

---

Generated by pr-bug-scan (proof-machine architecture). Human approval required before merge.

[pullfrog]

Reviewed changes — fixes a bug where listIssues passed first values > 50 to Linear's GraphQL API (cap at 50), causing requests to fail when users clicked "Load more" past the initial 36-item page. Replaces single-request fetching with a cursor-walking loop that paginates at 50 per rawRequest call and accumulates up to effectiveLimit.

• Add LINEAR_ISSUE_API_PAGE_SIZE_MAX and endCursor to pageInfo — caps per-request page size at 50 and surfaces the cursor from Linear's connection response.
• Add $after / endCursor to all 4 GraphQL queries — ALL_ISSUES_QUERY, VIEWER_ASSIGNED_ISSUES_QUERY, and VIEWER_CREATED_ISSUES_QUERY now accept and return pagination cursors.
• Refactor listIssues with fetchPage helper and cursor-walking loop — each rawRequest sends min(50, remaining), walks endCursor until effectiveLimit is reached or the server reports no more pages, with guards against stuck cursors and empty pages.

✅ No new issues found.

  ^{｜ View workflow run ｜ Using DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏}