Add Automated Stale Issue Management GitHub Action#1039
Add Automated Stale Issue Management GitHub Action#1039Varun-S10 wants to merge 4 commits intogoogle:mainfrom
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new 'stale agent' tool designed to automate the management of inactive GitHub issues using an LLM-based auditor. It includes the agent logic, tool definitions for GitHub actions, and a runner with concurrency support. Feedback focuses on improving the issue search criteria to use update timestamps, correcting invalid dependency versions in package.json, and ensuring the agent maintains necessary comment context during history analysis. Recommendations were also made to handle API pagination for collaborators and to validate critical environment variables at startup.
|
|
||
| const cutoffStr = cutoffDate.toISOString().replace(/\.\d{3}Z$/, 'Z'); | ||
|
|
||
| const query = `repo:${owner}/${repo} is:issue state:open created:<${cutoffStr}`; |
There was a problem hiding this comment.
The search query uses created:<${cutoffStr}, which filters issues based on when they were first opened. For a stale issue manager, it is more appropriate to filter by the last update time (updated:<${cutoffStr}). Using created will miss issues that were recently active but are old, and it will fail to identify newer issues that have become inactive.
| const query = `repo:${owner}/${repo} is:issue state:open created:<${cutoffStr}`; | |
| const query = `repo:${owner}/${repo} is:issue state:open updated:<${cutoffStr}`; |
There was a problem hiding this comment.
I don't know about this. You should reply with your plan
| "axios": "^1.14.0", | ||
| "axios-retry": "^4.5.0", | ||
| "date-fns": "^4.1.0", | ||
| "dotenv": "^17.3.1", | ||
| "luxon": "^3.7.2" | ||
| }, | ||
| "devDependencies": { | ||
| "@google/adk-devtools": "^0.6.0", | ||
| "@types/luxon": "^3.7.1", | ||
| "@types/node": "^25.5.0", | ||
| "ts-node": "^10.9.2", | ||
| "typescript": "^6.0.2" |
There was a problem hiding this comment.
Several dependency versions specified here (e.g., axios: ^1.14.0, typescript: ^6.0.2, luxon: ^3.7.2) do not currently exist. For example, the latest stable version of axios is 1.7.x and typescript is 5.x. Using non-existent versions will cause npm install to fail. Please verify and use valid semantic versions.
| } else { | ||
| last_comment_text = null; | ||
| } |
There was a problem hiding this comment.
The last_comment_text is currently reset to null if the most recent event in the history is not a comment (e.g., a rename or a label change). However, the LLM prompt (STEP 3) requires analyzing the maintainer's last comment text even if they performed subsequent actions. Resetting this field prevents the agent from accessing the necessary context.
}| const url = `${GITHUB_BASE_URL}/repos/${OWNER}/${REPO}/collaborators`; | ||
| const params = {permission: 'push'}; | ||
|
|
||
| const data = await getRequest<GitHubUser[]>(url, params); |
There was a problem hiding this comment.
The GitHub API call to /collaborators is paginated and defaults to 30 items. For repositories with many contributors, this will return an incomplete list, leading the bot to misidentify maintainers as regular users. You should implement pagination or at least set a high per_page limit (up to 100) and check if more results are available.
There was a problem hiding this comment.
Def set higher page limit
| export const OWNER = process.env.OWNER ?? ''; | ||
| export const REPO = process.env.REPO ?? ''; | ||
| export const LLM_MODEL_NAME = process.env.LLM_MODEL_NAME ?? ''; | ||
| export const STALE_LABEL_NAME = process.env.STALE_LABEL_NAME ?? ''; | ||
| export const REQUEST_CLARIFICATION_LABEL = | ||
| process.env.REQUEST_CLARIFICATION_LABEL ?? ''; |
There was a problem hiding this comment.
Critical configuration variables like OWNER, REPO, and LLM_MODEL_NAME default to empty strings if the environment variables are missing. This will cause subsequent API calls to fail with confusing errors (e.g., 404s). It is better to validate these at startup and throw a clear error message, similar to how GITHUB_TOKEN is handled.
There was a problem hiding this comment.
This seems like a reasonable recommendation. Can we do it please?
3 participants
PR Description:
This PR adds automation to help us manage issues. This keeps our repository organized and focused. The script acts as an automated helper, finding and resolving inactive discussions.
Why This Is Needed:
How It Works (Main Steps):
The script follows clear rules based on issue activity and who is commenting:
1. Marking as Stale: If an issue has no activity for {stale_threshold_days} days, it will be marked with the '{STALE_LABEL_NAME}' label and receive a comment asking for an update.
2. Closing Inactive Issues: If an issue remains stale (no activity from the author or other users) for an additional {close_threshold_days} days after being marked stale, it will be automatically closed.
3. Recognizing Activity: Any new comment from the original author or another non-bot user will remove the '{STALE_LABEL_NAME}' label, making the issue active again. If someone edits the issue description without adding a comment, the script will notify maintainers so important updates aren't missed.
4. Understanding Maintainer Comments: If a maintainer's last comment is a discussion with another maintainer, the issue stays active. If a maintainer asked a question, requested more information, or gave a suggestion, and there's no response for {stale_threshold_days} days, the issue will be marked as stale and also get a '{REQUEST_CLARIFICATION_LABEL}' if it doesn't have one already. Simple status updates from maintainers keep the issue active.