chore: add reopen-issue-if-prs-open workflow#2
Conversation
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughA new GitHub Actions workflow is added that monitors closed issues and reopens them if open PRs remain linked. The workflow queries the issue timeline to identify candidate PRs, verifies their current linkage through Changes
Sequence Diagram(s)sequenceDiagram
participant GH as GitHub<br/>(Action Trigger)
participant API as GitHub GraphQL API
participant Logic as Workflow Logic
participant Issue as Issue System
GH->>Logic: workflow_call triggered<br/>(on issue closed event)
Logic->>API: Query issue timeline<br/>(get connected PRs)
API-->>Logic: Return timeline events<br/>(OPEN PRs only)
Logic->>Logic: Deduplicate PRs<br/>(by repo & number)
Note over Logic: For each PR candidate
loop Verify each PR
Logic->>API: Query PR's<br/>closingIssuesReferences
API-->>Logic: Return linked issues
Logic->>Logic: Verify target issue<br/>still in references
end
alt At least one PR verified
Logic->>Issue: Reopen issue
Issue-->>Logic: Issue reopened
Logic->>Logic: Log reopened with<br/>PR list
else No PRs verified
Logic->>Logic: Log issue<br/>stays closed
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@greptile review |
|
@greptile stop |
|
@greptile review |
|
Note to future self - Greptile was hanging forever because I needed to add the .github repo to the Greptile config. |
Greptile SummaryThis PR adds a reusable workflow that prevents GitHub from permanently closing issues when the first PR in a Graphite stack merges, replicating Linear's behavior of keeping issues open until all linked PRs are merged. The implementation uses a two-phase verification approach:
This handles both UI-linked PRs and keyword-linked PRs (Fixes, Closes, Resolves), including cross-repo references. The workflow correctly deduplicates PRs by repository and number before verification. Confidence Score: 4/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant Caller as Calling Workflow
participant WF as Reopen Workflow
participant GH as GitHub GraphQL API
participant REST as GitHub REST API
Caller->>WF: Trigger on issue closed event
WF->>WF: Extract issue number, owner, repo
WF->>GH: Query issue timeline<br/>(CONNECTED_EVENT, CROSS_REFERENCED_EVENT)
GH-->>WF: Return timeline nodes with PR references
WF->>WF: Filter for OPEN PRs
WF->>WF: Deduplicate by repo#number
loop For each candidate PR
WF->>GH: Query PR's closingIssuesReferences
GH-->>WF: Return closing issues
WF->>WF: Verify issue is still linked
end
alt Open linked PRs found
WF->>REST: Update issue state to 'open'
REST-->>WF: Issue reopened
WF->>WF: Log reopened with PR list
else No open linked PRs
WF->>WF: Log issue stays closed
end
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/reopen-issue-if-prs-open.yml:
- Around line 89-96: verifyResult.repository.pullRequest can be null for
deleted/inaccessible PRs, causing a crash when accessing
.closingIssuesReferences; modify the verification flow around the verifyResult
(the result of github.graphql with verifyQuery) to check that
verifyResult.repository and verifyResult.repository.pullRequest exist before
accessing .closingIssuesReferences or .nodes, and if missing simply skip this PR
(do not push to verifiedOpenPRs) and optionally log a debug/warn mentioning the
pr.number and owner/repo so inaccessible PRs are handled gracefully.
🧹 Nitpick comments (2)
.github/workflows/reopen-issue-if-prs-open.yml (2)
24-61: Consider pagination for issues with many timeline events.The query fetches only the first 100 timeline items. For issues with extensive history, some linked PRs could be missed. For most use cases, 100 is likely sufficient, but consider adding pagination or increasing the limit if this workflow will be used on long-lived issues with many cross-references.
64-67: Add defensive null check for timeline data.If the GraphQL response structure differs from expected (e.g., issue not found, permissions issue), accessing
result.repository.issue.timelineItems.nodescould throw. Consider adding a guard:🛡️ Proposed defensive check
+ const timelineItems = result.repository?.issue?.timelineItems?.nodes; + if (!timelineItems) { + console.log(`Could not retrieve timeline for issue #${issueNumber}`); + return; + } + - const timelineNodes = result.repository.issue.timelineItems.nodes; const prCandidates = timelineNodes + const prCandidates = timelineItems .map(node => node.subject || node.source) .filter(pr => pr && pr.state === 'OPEN');
1 participant
Problem
When using Graphite stacked PRs, we link all PRs in the stack to a single issue. GitHub's default behavior closes the issue when the first PR merges, even though other PRs in the stack are still open.
Proposed Solution
Add a reusable workflow that reopens issues when they're closed while linked PRs are still open. This replicates Linear's behavior where an issue only closes when ALL linked PRs are merged.
Considerations
closingIssuesReferencesto confirm current linkageREOPEN_ISSUES_TOKEN) with Issues (R/W) and Pull requests (R) permissionsFixes RequestNetwork/public-issues#131
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.