fix(github): bound issue and pull request comment fetching

[KrisBraun]

When converting an issue or pull request into a thread, the connector fetches that item's comments. The two paths behaved differently, and both were problematic at high comment volumes:

• Issue conversion paginated the comments endpoint with no upper bound — one request per 100 comments, all within a single execution.
• Pull request conversion fetched only the first page (100) of comments, reviews, and review comments, silently dropping anything beyond that.

A single sync pass converts many items in one execution (a channel batch, or a full page of followed items), so a batch of heavily-commented items could approach or exceed the connector runtime's per-execution request budget and fail the pass.

Change

A new shared helper fetchPagedList caps each comment/review list at MAX_COMMENT_PAGES (3 pages / 300 items) and stops early on the first short page. Both converters, fetchReviewComments, and the pull-request reopened key refresh now route through it, so the request count per execution is bounded regardless of comment volume.

• Comments are fetched newest-first where the endpoint supports a sort direction (issue/conversation comments, review comments), so an item over the cap keeps its most recent 300. The reviews endpoint has no sort direction, so those come back in default order (reviews are low-volume; the cap rarely applies).
• Items under the cap fetch everything — the common case (well under 100 comments) is a single request, unchanged.
• The item description is always kept.

Tests

Added pagination.test.ts (helper: stops on short page, caps at the page limit, best-effort on a non-OK response), issue-sync.test.ts (previously none), and convertPRToThread / reopened-key coverage in pr-sync.test.ts. Full connector suite: 79 passing; tsc --noEmit and build clean.

🤖 Generated with Claude Code

[KrisBraun]

When converting an issue or pull request into a thread, the connector fetches that item's comments. The two paths behaved differently, and both were problematic at high comment volumes:

• Issue conversion paginated the comments endpoint with no upper bound — one request per 100 comments, all within a single execution.
• Pull request conversion fetched only the first page (100) of comments, reviews, and review comments, silently dropping anything beyond that.

A single sync pass converts many items in one execution (a channel batch, or a full page of followed items), so a batch of heavily-commented items could approach or exceed the connector runtime's per-execution request budget and fail the pass.

Change

A new shared helper fetchPagedList caps each comment/review list at MAX_COMMENT_PAGES (3 pages / 300 items) and stops early on the first short page. Both converters, fetchReviewComments, and the pull-request reopened key refresh now route through it, so the request count per execution is bounded regardless of comment volume.

• Comments are fetched newest-first where the endpoint supports a sort direction (issue/conversation comments, review comments), so an item over the cap keeps its most recent 300. The reviews endpoint has no sort direction, so those come back in default order (reviews are low-volume; the cap rarely applies).
• Items under the cap fetch everything — the common case (well under 100 comments) is a single request, unchanged.
• The item description is always kept.

Tests

Added pagination.test.ts (helper: stops on short page, caps at the page limit, best-effort on a non-OK response), issue-sync.test.ts (previously none), and convertPRToThread / reopened-key coverage in pr-sync.test.ts. Full connector suite: 79 passing; tsc --noEmit and build clean.

🤖 Generated with Claude Code

[KrisBraun]

When converting an issue or pull request into a thread, the connector fetches that item's comments. The two paths behaved differently, and both were problematic at high comment volumes:

• Issue conversion paginated the comments endpoint with no upper bound — one request per 100 comments, all within a single execution.
• Pull request conversion fetched only the first page (100) of comments, reviews, and review comments, silently dropping anything beyond that.

A single sync pass converts many items in one execution (a channel batch, or a full page of followed items), so a batch of heavily-commented items could approach or exceed the connector runtime's per-execution request budget and fail the pass.

Change

A new shared helper fetchPagedList caps each comment/review list at MAX_COMMENT_PAGES (3 pages / 300 items) and stops early on the first short page. Both converters, fetchReviewComments, and the pull-request reopened key refresh now route through it, so the request count per execution is bounded regardless of comment volume.

• Comments are fetched newest-first where the endpoint supports a sort direction (issue/conversation comments, review comments), so an item over the cap keeps its most recent 300. The reviews endpoint has no sort direction, so those come back in default order (reviews are low-volume; the cap rarely applies).
• Items under the cap fetch everything — the common case (well under 100 comments) is a single request, unchanged.
• The item description is always kept.

Tests

Added pagination.test.ts (helper: stops on short page, caps at the page limit, best-effort on a non-OK response), issue-sync.test.ts (previously none), and convertPRToThread / reopened-key coverage in pr-sync.test.ts. Full connector suite: 79 passing; tsc --noEmit and build clean.

🤖 Generated with Claude Code

[KrisBraun]

When converting an issue or pull request into a thread, the connector fetches that item's comments. The two paths behaved differently, and both were problematic at high comment volumes:

• Issue conversion paginated the comments endpoint with no upper bound — one request per 100 comments, all within a single execution.
• Pull request conversion fetched only the first page (100) of comments, reviews, and review comments, silently dropping anything beyond that.

A single sync pass converts many items in one execution (a channel batch, or a full page of followed items), so a batch of heavily-commented items could approach or exceed the connector runtime's per-execution request budget and fail the pass.

Change

A new shared helper fetchPagedList caps each comment/review list at MAX_COMMENT_PAGES (3 pages / 300 items) and stops early on the first short page. Both converters, fetchReviewComments, and the pull-request reopened key refresh now route through it, so the request count per execution is bounded regardless of comment volume.

• Comments are fetched newest-first where the endpoint supports a sort direction (issue/conversation comments, review comments), so an item over the cap keeps its most recent 300. The reviews endpoint has no sort direction, so those come back in default order (reviews are low-volume; the cap rarely applies).
• Items under the cap fetch everything — the common case (well under 100 comments) is a single request, unchanged.
• The item description is always kept.

Tests

Added pagination.test.ts (helper: stops on short page, caps at the page limit, best-effort on a non-OK response), issue-sync.test.ts (previously none), and convertPRToThread / reopened-key coverage in pr-sync.test.ts. Full connector suite: 79 passing; tsc --noEmit and build clean.

🤖 Generated with Claude Code

[KrisBraun]

When converting an issue or pull request into a thread, the connector fetches that item's comments. The two paths behaved differently, and both were problematic at high comment volumes:

• Issue conversion paginated the comments endpoint with no upper bound — one request per 100 comments, all within a single execution.
• Pull request conversion fetched only the first page (100) of comments, reviews, and review comments, silently dropping anything beyond that.

A single sync pass converts many items in one execution (a channel batch, or a full page of followed items), so a batch of heavily-commented items could approach or exceed the connector runtime's per-execution request budget and fail the pass.

Change

A new shared helper fetchPagedList caps each comment/review list at MAX_COMMENT_PAGES (3 pages / 300 items) and stops early on the first short page. Both converters, fetchReviewComments, and the pull-request reopened key refresh now route through it, so the request count per execution is bounded regardless of comment volume.

• Comments are fetched newest-first where the endpoint supports a sort direction (issue/conversation comments, review comments), so an item over the cap keeps its most recent 300. The reviews endpoint has no sort direction, so those come back in default order (reviews are low-volume; the cap rarely applies).
• Items under the cap fetch everything — the common case (well under 100 comments) is a single request, unchanged.
• The item description is always kept.

Tests

Added pagination.test.ts (helper: stops on short page, caps at the page limit, best-effort on a non-OK response), issue-sync.test.ts (previously none), and convertPRToThread / reopened-key coverage in pr-sync.test.ts. Full connector suite: 79 passing; tsc --noEmit and build clean.

🤖 Generated with Claude Code

[KrisBraun]

When converting an issue or pull request into a thread, the connector fetches that item's comments. The two paths behaved differently, and both were problematic at high comment volumes:

• Issue conversion paginated the comments endpoint with no upper bound — one request per 100 comments, all within a single execution.
• Pull request conversion fetched only the first page (100) of comments, reviews, and review comments, silently dropping anything beyond that.

A single sync pass converts many items in one execution (a channel batch, or a full page of followed items), so a batch of heavily-commented items could approach or exceed the connector runtime's per-execution request budget and fail the pass.

Change

A new shared helper fetchPagedList caps each comment/review list at MAX_COMMENT_PAGES (3 pages / 300 items) and stops early on the first short page. Both converters, fetchReviewComments, and the pull-request reopened key refresh now route through it, so the request count per execution is bounded regardless of comment volume.

• Comments are fetched newest-first where the endpoint supports a sort direction (issue/conversation comments, review comments), so an item over the cap keeps its most recent 300. The reviews endpoint has no sort direction, so those come back in default order (reviews are low-volume; the cap rarely applies).
• Items under the cap fetch everything — the common case (well under 100 comments) is a single request, unchanged.
• The item description is always kept.

Tests

Added pagination.test.ts (helper: stops on short page, caps at the page limit, best-effort on a non-OK response), issue-sync.test.ts (previously none), and convertPRToThread / reopened-key coverage in pr-sync.test.ts. Full connector suite: 79 passing; tsc --noEmit and build clean.

🤖 Generated with Claude Code

[KrisBraun]

When converting an issue or pull request into a thread, the connector fetches that item's comments. The two paths behaved differently, and both were problematic at high comment volumes:

• Issue conversion paginated the comments endpoint with no upper bound — one request per 100 comments, all within a single execution.
• Pull request conversion fetched only the first page (100) of comments, reviews, and review comments, silently dropping anything beyond that.

A single sync pass converts many items in one execution (a channel batch, or a full page of followed items), so a batch of heavily-commented items could approach or exceed the connector runtime's per-execution request budget and fail the pass.

Change

A new shared helper fetchPagedList caps each comment/review list at MAX_COMMENT_PAGES (3 pages / 300 items) and stops early on the first short page. Both converters, fetchReviewComments, and the pull-request reopened key refresh now route through it, so the request count per execution is bounded regardless of comment volume.

• Comments are fetched newest-first where the endpoint supports a sort direction (issue/conversation comments, review comments), so an item over the cap keeps its most recent 300. The reviews endpoint has no sort direction, so those come back in default order (reviews are low-volume; the cap rarely applies).
• Items under the cap fetch everything — the common case (well under 100 comments) is a single request, unchanged.
• The item description is always kept.

Tests

Added pagination.test.ts (helper: stops on short page, caps at the page limit, best-effort on a non-OK response), issue-sync.test.ts (previously none), and convertPRToThread / reopened-key coverage in pr-sync.test.ts. Full connector suite: 79 passing; tsc --noEmit and build clean.

🤖 Generated with Claude Code

[KrisBraun]

When converting an issue or pull request into a thread, the connector fetches that item's comments. The two paths behaved differently, and both were problematic at high comment volumes:

• Issue conversion paginated the comments endpoint with no upper bound — one request per 100 comments, all within a single execution.
• Pull request conversion fetched only the first page (100) of comments, reviews, and review comments, silently dropping anything beyond that.

A single sync pass converts many items in one execution (a channel batch, or a full page of followed items), so a batch of heavily-commented items could approach or exceed the connector runtime's per-execution request budget and fail the pass.

Change

A new shared helper fetchPagedList caps each comment/review list at MAX_COMMENT_PAGES (3 pages / 300 items) and stops early on the first short page. Both converters, fetchReviewComments, and the pull-request reopened key refresh now route through it, so the request count per execution is bounded regardless of comment volume.

• Comments are fetched newest-first where the endpoint supports a sort direction (issue/conversation comments, review comments), so an item over the cap keeps its most recent 300. The reviews endpoint has no sort direction, so those come back in default order (reviews are low-volume; the cap rarely applies).
• Items under the cap fetch everything — the common case (well under 100 comments) is a single request, unchanged.
• The item description is always kept.

Tests

Added pagination.test.ts (helper: stops on short page, caps at the page limit, best-effort on a non-OK response), issue-sync.test.ts (previously none), and convertPRToThread / reopened-key coverage in pr-sync.test.ts. Full connector suite: 79 passing; tsc --noEmit and build clean.

🤖 Generated with Claude Code