.github/workflows/pr_governance (4)

126-219: Best-effort manual link detection may be expensive for large repositories.

Scanning up to 1000 issues to find ConnectedEvent timeline items that reference this PR could consume significant API quota and add latency for repositories with many issues. This is acknowledged with the warning at line 212-216, but consider documenting this behavior for maintainers.

The approach is reasonable given GitHub's API limitations, but if performance becomes an issue, consider caching results or reducing maxIssuePages with appropriate documentation about the trade-off.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/pr_governance around lines 126 - 219, The
getSameRepoManuallyLinkedIssues function performs an unbounded (up to
maxIssuePages) scan of issues which can be very expensive for large repos; to
mitigate, document this behavior and provide an opt-out/config option and a
lower default cap: add a clear comment and README note that scanning up to
maxIssuePages (currently 10) may consume API quota, expose maxIssuePages (or a
boolean to disable the scan) as a configurable parameter, and ensure the
warnings.push message refers to that config so maintainers can adjust or disable
the github.graphql pagination scan if needed.

---

41-42: Closing keyword regex requires whitespace, but GitHub allows closes#123.

The regex requires at least one whitespace (\s+) after the optional colon, so patterns like closes#123 or fixes#456 (no space) won't match. GitHub actually recognizes these as valid closing keywords. Since the actual linked issues come from the GraphQL API (closingIssuesReferences), this only affects the hasClosingKeywordText boolean used for diagnostics, making the impact minor.

♻️ Proposed fix to allow zero whitespace

 const closingKeywordRegex =
-  /\b(?:close|closes|closed|fix|fixes|fixed|resolve|resolves|resolved)\b\s*:?\s+(?:[A-Za-z0-9_.-]+\/[A-Za-z0-9_.-]+)?#\d+\b/i;
+  /\b(?:close|closes|closed|fix|fixes|fixed|resolve|resolves|resolved)\b\s*:?\s*(?:[A-Za-z0-9_.-]+\/[A-Za-z0-9_.-]+)?#\d+\b/i;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/pr_governance around lines 41 - 42, The diagnostic regex
stored in closingKeywordRegex requires at least one whitespace after the
optional colon which misses matches like "closes#123"; update the pattern by
replacing the `\s+` with `\s*` so zero or more whitespace characters are allowed
(keep the rest of the regex and the case-insensitive flag intact) to match both
"closes `#123`" and "closes#123".

---

273-298: Dead code: issueNodeId is always populated from upstream functions.

The condition at line 278 (!issueNodeId) will never be true because both getKeywordLinkedIssuesFromPR (line 91) and getSameRepoManuallyLinkedIssues (line 198-199) always populate the id field. The fallback logic to call getSameRepoIssueNodeId is unreachable.

♻️ Proposed fix to remove dead code

 for (const linkedIssue of linkedIssues) {
   try {
-    let issueNodeId = linkedIssue.id;
-
-    // If the issue is in the same repo and we only have the number, refresh via REST if needed.
-    if (!issueNodeId && linkedIssue.repository?.nameWithOwner === `${owner}/${repo}`) {
-      issueNodeId = await getSameRepoIssueNodeId(linkedIssue.number);
-    }
+    const issueNodeId = linkedIssue.id;

     if (!issueNodeId) {
       warnings.push(

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/pr_governance around lines 273 - 298, The branch that
checks and refreshes issueNodeId is dead because linkedIssue.id is always set by
getKeywordLinkedIssuesFromPR and getSameRepoManuallyLinkedIssues; remove the
unreachable if-block that calls getSameRepoIssueNodeId and the associated
warning about unresolved node ID, and simplify the loop to assume issueNodeId
exists (keeping error handling around getProjectCountForContent and the catch
that pushes the validation warning). Update references to issueNodeId,
linkedIssue, getProjectCountForContent, getKeywordLinkedIssuesFromPR,
getSameRepoManuallyLinkedIssues, and getSameRepoIssueNodeId accordingly (remove
the unreachable getSameRepoIssueNodeId usage and related message).

---

321-326: sameRepoRefsInBody may include PR references, not just issues.

The regex at line 44 matches any #N pattern, which includes references to PRs as well as issues. This could produce a misleading warning suggesting manual linking when the body actually references other PRs (e.g., "Related to #1234" where #1234 is a PR).

Consider validating that the numbers correspond to actual issues before emitting this diagnostic, or clarifying the warning text.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/pr_governance around lines 321 - 326, The warning is being
triggered by extractSameRepoIssueNumbersFromBody returning any `#N` (which can be
PRs), so update the logic that builds sameRepoRefsInBody (or post-filter it) to
only include numbers that are actual issues before pushing the warning: either
call the existing linkedIssues (or a new helper like isIssueNumber) to verify
each referenced number is an issue (not a PR) via the repo metadata/GitHub API
and filter out PR numbers, or change the warning text to explicitly say
"references other PRs/issues" instead of implying manual linking; ensure you
update the code paths around sameRepoRefsInBody, hasClosingKeywordText,
linkedIssues and warnings so the warning is emitted only when a referenced
number is confirmed to be an issue.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes