fix: improve auto close filter logic

[johnnyeric]

Context

Improve stale PR detection so review-thread comments count as PR activity before auto-closing.

Implementation

Fetch PRs through GraphQL with commits, issue comments, reviews, and review-thread comments, then close only PRs whose latest activity is older than the cutoff. Keep issue closing on the existing oldest-updated scan.

Screenshots / Video

N/A, workflow-only change.

How to Test

Manual/local verification

• Agent: bun run script/check-workflows.ts successfully.

Reviewer test steps

1. Run the kilo-auto-close workflow with dryRun: true.
2. Confirm PRs with recent review-thread comments are logged as fresh.
3. Confirm stale PRs and issues are only logged, not closed.

Checklist

• Issue linked above, or exception explained
• Tests/verification described
• Screenshots/video included for visual changes, or marked N/A
• Changeset considered for user-facing changes
• I personally reviewed the diff and can explain the changes, including any AI-assisted work.

Get in Touch

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 485efb14a0

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[kilo-code-bot]

Code Review Summary

Status: 1 Issue Found | Recommendation: Low risk, merge at discretion

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
.github/workflows/kilo-auto-close.yml	128	reviewThreads(last: 100) silently caps at 100 threads — a PR with >100 review threads could appear stale when it's actually active

Issue Notes

reviewThreads(last: 100) cap (line 128)

The GraphQL query fetches at most 100 review threads per PR. If a PR has accumulated more than 100 review threads, only the 100 most recent are returned. Because comments(last: 1) correctly picks the latest comment per thread, the cap only becomes a problem if the oldest thread (beyond position 100) contains the most recent activity — which is extremely unlikely in practice. The cap is acceptable for a CI workflow, but worth noting.

A workaround if this ever becomes a concern would be to paginate reviewThreads or raise the limit to 250 (GitHub's max).

---

Everything else looks correct:

• entry() / latest() helper design is clean and the flatMap pattern for attaching activity metadata to stale PRs is a nice improvement.
• comments(last: 1) correctly retrieves the most recent comment in each review thread (GraphQL last returns in ascending order, so nodes[0] is that single element).
• Issue activity stays a raw Date (accessed via .toISOString()) while PR activity is the richer { date, source } object — this asymmetry is consistent with the logging format.
• The falsy guard if (!date) return null in entry() safely handles both null and undefined dates.
• entry("created", pr.createdAt) is always non-null, so activity will never be undefined in practice; the !activity guard is safe defensive coding.
• New commit (1fb72095) introduces no additional issues — log messages with activity source info are a clean improvement.

Files Reviewed (1 file)

• .github/workflows/kilo-auto-close.yml — 1 warning (carried forward, not fixed in latest commit)

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-4.6-sonnet-20260217 · 455,805 tokens}

_{Review guidance: REVIEW.md from base branch main}