Discussion management #426

mvadari · 2025-12-23T18:38:17Z

This PR adds a bot that manages discussions in this repo. It comments in a discussion when it is old and closes and locks it if nobody responds.

Example: #97 (comment)

…ment

Copilot

Pull request overview

This PR introduces an automated discussion management system that identifies stale discussions (inactive for over ~3 years), warns users about impending closure, and automatically closes/locks discussions that remain inactive for 30 days after the warning.

Key Changes:

Added a GitHub Actions workflow that runs weekly to process stale discussions
Implemented a bash script that uses GitHub's GraphQL API to identify, warn, and close inactive discussions
Configured authentication via GitHub App for API access

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 10 comments.

File	Description
.github/workflows/discussions.yml	Defines the scheduled workflow with environment variables for stale thresholds, warning/close messages, and integrates with a GitHub App for authentication
.github/scripts/process-stale-discussions.sh	Implements the core logic to fetch discussions via GraphQL, identify which need warnings or closure based on age, and execute the appropriate actions

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-05T20:42:06Z

.github/workflows/discussions.yml

+  contents: read # Required to checkout the repository
+
+env:
+  STALE_DAYS: 1000 # 365 * 3 # Number of days without updates to consider a discussion stale


The STALE_DAYS is set to 1000 days (approximately 2.7 years) but the comment says "365 * 3" which equals 1095 days. There's a mismatch between the actual value (1000) and the comment (365 * 3 = 1095). Either update the value to 1095 or change the comment to reflect 1000 days.

Suggested change

STALE_DAYS: 1000 # 365 * 3 # Number of days without updates to consider a discussion stale

STALE_DAYS: 1000 # Number of days without updates (≈2.7 years) to consider a discussion stale

.github/scripts/process-stale-discussions.sh

Copilot · 2026-01-05T20:42:08Z

.github/scripts/process-stale-discussions.sh

+gh api graphql -f query='
+  query($owner: String!, $repo: String!, $cursor: String) {
+    repository(owner: $owner, name: $repo) {
+      discussions(first: 100, after: $cursor, orderBy: {field: UPDATED_AT, direction: ASC}) {
+        pageInfo {
+          hasNextPage
+          endCursor
+        }
+        nodes {
+          id
+          number
+          title
+          url
+          createdAt
+          updatedAt
+          closed
+          locked
+          comments(last: 10) {
+            nodes {
+              body
+              createdAt
+              author {
+                login
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+' -f owner="$GITHUB_REPOSITORY_OWNER" -f repo="$GITHUB_REPOSITORY_NAME" > discussions.json


The GraphQL query only fetches the first 100 discussions and doesn't implement pagination despite having pageInfo.hasNextPage and endCursor fields. If the repository has more than 100 discussions, only the first 100 will be processed. Implement pagination to process all discussions in the repository.

Copilot · 2026-01-05T20:42:08Z

.github/scripts/process-stale-discussions.sh

+# 3. The discussion hasn't been updated since the warning (or updates are also old)
+echo ""
+echo "=== Discussions to close - warned ${WARNING_DAYS}+ days ago with no activity ==="
+cat discussions.json | jq -r --arg warningCutoff "$CLOSE_CUTOFF" '.data.repository.discussions.nodes[] | select(.closed == false) | . as $discussion | ((.comments.nodes // []) | map(select(.body | contains("will be closed in 30 days"))) | last) as $warningComment | select($warningComment != null) | select($warningComment.createdAt < $warningCutoff) | select($discussion.updatedAt <= $warningComment.createdAt or $discussion.updatedAt < $warningCutoff) | @json' | while IFS= read -r discussion; do


The condition 'select($discussion.updatedAt <= $warningComment.createdAt or $discussion.updatedAt < $warningCutoff)' on line 76 has a logic issue. The second part '$discussion.updatedAt < $warningCutoff' is redundant because if the warning comment was created before CLOSE_CUTOFF and the discussion hasn't been updated since the warning, then updatedAt would already be less than warningCutoff. This could also incorrectly close discussions where someone replied after the warning but the reply is still older than the close cutoff. Consider simplifying to just check if the discussion hasn't been updated since the warning comment.

Suggested change

cat discussions.json | jq -r --arg warningCutoff "$CLOSE_CUTOFF" '.data.repository.discussions.nodes[] | select(.closed == false) | . as $discussion | ((.comments.nodes // []) | map(select(.body | contains("will be closed in 30 days"))) | last) as $warningComment | select($warningComment != null) | select($warningComment.createdAt < $warningCutoff) | select($discussion.updatedAt <= $warningComment.createdAt or $discussion.updatedAt < $warningCutoff) | @json' | while IFS= read -r discussion; do

cat discussions.json | jq -r --arg warningCutoff "$CLOSE_CUTOFF" '.data.repository.discussions.nodes[] | select(.closed == false) | . as $discussion | ((.comments.nodes // []) | map(select(.body | contains("will be closed in 30 days"))) | last) as $warningComment | select($warningComment != null) | select($warningComment.createdAt < $warningCutoff) | select($discussion.updatedAt <= $warningComment.createdAt) | @json' | while IFS= read -r discussion; do

Copilot · 2026-01-05T20:42:08Z

.github/workflows/discussions.yml

+name: Stale GitHub Discussions
+
+on:
+  pull_request: # just for debug purposes


The workflow trigger includes "pull_request" with a comment indicating it's "just for debug purposes". Debug triggers should not be included in production code. Remove this trigger before merging to production, or use workflow_dispatch for manual testing instead.

Suggested change

pull_request: # just for debug purposes

Copilot · 2026-01-05T20:42:09Z

.github/scripts/process-stale-discussions.sh

+#    b. It has a warning but was updated after that warning (user responded, so we warn again)
+echo ""
+echo "=== Discussions to warn - stale for ${STALE_DAYS}+ days, not yet warned ==="
+cat discussions.json | jq -r --arg staleCutoff "$STALE_CUTOFF" '.data.repository.discussions.nodes[] | select(.closed == false) | select(.updatedAt < $staleCutoff) | . as $discussion | ((.comments.nodes // []) | map(select(.body | contains("will be closed in 30 days"))) | last) as $warningComment | select($warningComment == null or $discussion.updatedAt > $warningComment.createdAt) | @json' | while IFS= read -r discussion; do


The same hardcoded string "will be closed in 30 days" is used here for detecting warning comments. This creates a tight coupling with the WARNING_MESSAGE content and will break if WARNING_DAYS or the message format changes. Consider using a unique marker or tag in the warning message that doesn't depend on the specific day count.

Copilot · 2026-01-05T20:42:09Z

.github/scripts/process-stale-discussions.sh

+      gh api graphql -f query='mutation($discussionId: ID!, $body: String!) { addDiscussionComment(input: {discussionId: $discussionId, body: $body}) { comment { id } } }' -f discussionId="$DISCUSSION_ID" -f body="$CLOSE_MESSAGE"
+
+      # Step 2: Close the discussion
+      echo "  Closing discussion..."
+      gh api graphql -f query='mutation($discussionId: ID!) { closeDiscussion(input: {discussionId: $discussionId}) { discussion { id } } }' -f discussionId="$DISCUSSION_ID"
+
+      # Step 3: Lock the discussion to prevent further comments
+      echo "  Locking discussion..."
+      gh api graphql -f query='mutation($discussionId: ID!) { lockLockable(input: {lockableId: $discussionId}) { lockedRecord { locked } } }' -f discussionId="$DISCUSSION_ID"


The error handling could be improved here. If the gh api graphql mutation fails (for adding a comment, closing, or locking), the script will exit due to 'set -e' on line 2, but there's no cleanup or rollback logic. Consider adding error handling to ensure partial operations don't leave discussions in an inconsistent state (e.g., commented but not closed).

Suggested change

gh api graphql -f query='mutation($discussionId: ID!, $body: String!) { addDiscussionComment(input: {discussionId: $discussionId, body: $body}) { comment { id } } }' -f discussionId="$DISCUSSION_ID" -f body="$CLOSE_MESSAGE"

# Step 2: Close the discussion

echo " Closing discussion..."

gh api graphql -f query='mutation($discussionId: ID!) { closeDiscussion(input: {discussionId: $discussionId}) { discussion { id } } }' -f discussionId="$DISCUSSION_ID"

# Step 3: Lock the discussion to prevent further comments

echo " Locking discussion..."

gh api graphql -f query='mutation($discussionId: ID!) { lockLockable(input: {lockableId: $discussionId}) { lockedRecord { locked } } }' -f discussionId="$DISCUSSION_ID"

if ! gh api graphql -f query='mutation($discussionId: ID!, $body: String!) { addDiscussionComment(input: {discussionId: $discussionId, body: $body}) { comment { id } } }' -f discussionId="$DISCUSSION_ID" -f body="$CLOSE_MESSAGE"; then

echo " Error: Failed to add close comment for discussion #$DISCUSSION_NUMBER. Skipping close/lock for this discussion."

echo ""

continue

fi

# Step 2: Close the discussion

echo " Closing discussion..."

if ! gh api graphql -f query='mutation($discussionId: ID!) { closeDiscussion(input: {discussionId: $discussionId}) { discussion { id } } }' -f discussionId="$DISCUSSION_ID"; then

echo " Error: Failed to close discussion #$DISCUSSION_NUMBER after adding close comment. Skipping lock for this discussion."

echo ""

continue

fi

# Step 3: Lock the discussion to prevent further comments

echo " Locking discussion..."

if ! gh api graphql -f query='mutation($discussionId: ID!) { lockLockable(input: {lockableId: $discussionId}) { lockedRecord { locked } } }' -f discussionId="$DISCUSSION_ID"; then

echo " Warning: Failed to lock discussion #$DISCUSSION_NUMBER after closing it. Discussion remains closed but unlocked."

fi

.github/scripts/process-stale-discussions.sh

Co-authored-by: Copilot <[email protected]>

mvadari and others added 30 commits September 5, 2025 12:55

add stale discussion check

edd08cf

use sofa script

9968c96

Merge branch 'master' into discussion-management

5f4f3aa

oops

a0691b4

change owner

d92cf91

update script link

8fd37d6

Merge branch 'master' into discussion-management

096d22a

attempt #2

5b1103d

run forreal (fingers crossed)

0c97dbf

fix

346a2e6

fix

6a46309

try again

32980e8

better error handling

85b299e

fix hopefully?

5b3909d

Merge remote-tracking branch 'upstream/master' into discussion-manage…

00bfb34

…ment

try different URL

097b2b3

switch back to graphql

474fcbf

try again

e0b524f

accidentally removed run

4adf9d5

try again

e191f7c

try again

8b46fbe

augment attempt

a0dcde5

change to updated, exclude closed

e67265c

Merge branch 'master' into discussion-management

dd79f39

test out full flow

9981bd1

fix

c709059

try again

a64ffe3

try one more time

cec3031

fingers crossed

86ffea7

new error

1662244

mvadari added 11 commits December 17, 2025 15:37

add comments

19bf175

switch to 3 years for testing

bf74962

test (fingers crossed...)

90f7826

fix permissions

514175e

try again

cea9b55

fix secret name

b698163

debug

8635770

try again

7fff2cf

try again

29cae03

add dry run

8ca726f

try the app

ecf3b23

mvadari mentioned this pull request Dec 23, 2025

add stale discussion check #359

Closed

mvadari added 2 commits December 23, 2025 10:45

change time

2eb752e

try to skip chmod step

f36132d

mvadari requested a review from Copilot January 5, 2026 20:37

Copilot started reviewing on behalf of mvadari January 5, 2026 20:38 View session

Copilot AI reviewed Jan 5, 2026

View reviewed changes

Apply suggestions from code review

d1f8fc0

Co-authored-by: Copilot <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Discussion management #426

Discussion management #426

Uh oh!

mvadari commented Dec 23, 2025 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Jan 5, 2026

Uh oh!

Copilot AI Jan 5, 2026

Uh oh!

Copilot AI Jan 5, 2026

Uh oh!

Copilot AI Jan 5, 2026

Uh oh!

Copilot AI Jan 5, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	STALE_DAYS: 1000 # 365 * 3 # Number of days without updates to consider a discussion stale
	STALE_DAYS: 1000 # Number of days without updates (≈2.7 years) to consider a discussion stale

Discussion management #426

Are you sure you want to change the base?

Discussion management #426

Uh oh!

Conversation

mvadari commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mvadari commented Dec 23, 2025 •

edited

Loading