feat: batch inline comments into a single PR review submission

[hashwnath]

Fixes #1049

Problem

The post-processing step posts each buffered inline comment as an individual createReviewComment API call. For a review with N inline comments, this generates N separate email notifications and N disconnected entries in the PR timeline — noisy and hard to review as a whole.

Solution

Replace the individual comment loop with a single createReview() API call that submits all inline comments together as one cohesive PR review with event: "COMMENT". This:

• Produces one notification instead of N
• Creates a single review entry in GitHub's "Reviews" tab
• Matches the experience of a human reviewer submitting a batch review
• Is fully backward-compatible: if the batch call fails (e.g. one comment targets an invalid path/line), it falls back to posting comments individually

Changes

• src/entrypoints/post-buffered-inline-comments.ts: Added postCommentsAsReview() that maps buffered comments to the pulls.createReview API format and submits them as a single review. The existing postComment() function is retained as the fallback path.

Testing

• All 653 existing tests pass
• TypeScript type checking passes
• Prettier formatting passes
• The postComment() fallback ensures no regressions — if batch submission fails for any reason, comments are posted individually as before

[suramkavyasree]

❌ Code Review: Changes Requested

The code effectively consolidates inline comments into a single review submission, reducing notification noise and improving review coherence. However, there are high-priority issues such as missing type hints, improper logging, and a bare except block that need addressing.

Issue Summary

Severity	Count
⚠️ High	3
🔵 Low	1

---

Automated review by Code Review Agent

[suramkavyasree]

⚠️ HIGH: Missing type hints for public function parameters and return value

The function postCommentsAsReview lacks type hints for its parameters and return value.

Why this matters: Type hints improve code readability and help with static analysis, making it easier to understand and maintain the code.

Suggested fix:

Add type hints for all parameters and the return value of the function.

[suramkavyasree]

⚠️ HIGH: Use of console.log instead of structlog logger

The code uses console.log for logging, which is not suitable for production environments.

Why this matters: Using a structured logger like structlog provides better logging capabilities, such as log levels, structured data, and better integration with logging systems.

Suggested fix:

Replace console.log with structlog logger.

[suramkavyasree]

⚠️ HIGH: Bare except used in catch block

The catch block uses a bare exception handling pattern, which can swallow all exceptions, including system-exiting ones.

Why this matters: Using a bare except can hide bugs and make debugging difficult. It's important to catch specific exceptions to handle known error conditions.

Suggested fix:

Catch specific exceptions instead of using a bare except.

[suramkavyasree]

🔵 LOW: Missing Google-style docstring for public function

The function postCommentsAsReview lacks a Google-style docstring with Args, Returns, and Raises sections.

Why this matters: Comprehensive docstrings provide clear documentation for function usage, expected inputs, outputs, and potential exceptions.

Suggested fix:

Add a Google-style docstring with Args, Returns, and Raises sections.

[BillChirico]

This looks amazing and highly needed! Would love to see this merged.

[lokeshwarobuli]

Same here !!!