[Bug] LinkBot

[exploreriii]

Linkbot is missing the right permissions to execute:

See here
https://github.com/hiero-ledger/hiero-sdk-python/actions/runs/20410875001/job/58653643143?pr=1182

data: {
  message: 'Resource not accessible by integration',
  documentation_url: 'https://docs.github.com/rest/issues/comments#create-an-issue-comment',
  status: '403'
}

},
request: {
method: 'POST',
url: 'https://api.github.com/repos/hiero-ledger/hiero-sdk-python/issues/1182/comments',
headers: {
accept: 'application/vnd.github.v3+json',
'user-agent': 'actions/github-script octokit-core.js/5.0.1 Node.js/24',
authorization: 'token [REDACTED]',
'content-type': 'application/json; charset=utf-8'
},
body: '{"body":"Hi @sarthak-cs, this is LinkBot 👋\n\nLinking pull requests to issues helps us significantly with reviewing pull requests and keeping the repository healthy.\n\n🚨 This pull request does not have an issue linked.\n\nPlease link an issue using the following format:\n- Fixes #123\n\n📖 Guide:\ndocs/sdk_developers/how_to_link_issues.md\n\nIf no issue exists yet, please create one:\ndocs/sdk_developers/creating_issues.md\n\nThanks!"}',
request: {
agent: [Agent],
fetch: [Function: proxyFetch],
hook: [Function: bound bound register]
}
}
}

Issue is to debug and solve 🥇

.github/workflows/pr-missing-linked-issue.yml

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• [Intermediate]: Create workflow that sends a reminder to link an isssue to a PR #1144
• [Good First Issue]: Rename .github/workflows/pr-missing-linked-issue.yml to .github/workflows/bot-pr-missing-linked-issue.yml #1175
• Create .github/workflow to auto-close PRs with no linked issue after 3 days #1145

🔗 Related PRs

#1123 - feat: Add workflow to notify team about Good first issues [merged]
#1168 - fix: Workflow permissions for test file naming checks and codecov [merged]
#1173 - feat(ci): add workflow to remind pull requests to link issues [merged]

👤 Suggested Assignees

• exploreriii
• kplnosmn94-droid
• manishdait
• undefinedIsMyLife

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitai]

Coding Plan

Approach

Fix the LinkBot workflow that's currently failing with a 403 "Resource not accessible by integration" error when attempting to comment on pull requests from forked repositories.

Observations

The project uses GitHub Actions workflows for automation, located in .github/workflows/ with supporting JavaScript scripts in .github/scripts/. The LinkBot functionality is implemented through the pr-missing-linked-issue.yml workflow that triggers on PR events and executes pr_missing_linked_issue.js via the actions/github-script action. Other workflows in the repository (like bot-pr-auto-draft-on-changes.yml, bot-merge-conflict.yml, and bot-verified-commits.yml) successfully interact with PRs using similar patterns. The JavaScript scripts follow a pattern of receiving pre-authenticated github and context objects from the GitHub Actions runner.

Assumptions

Assumption 1: Root cause of the 403 error

Options Considered:

• Keep pull_request trigger and request special repository permissions
• Switch to pull_request_target trigger

Chosen Option: Switch to pull_request_target trigger

Rationale: This is the standard solution for workflows that need to comment on PRs from forks, as evidenced by the exploration findings showing this is a common pattern for bot workflows. The trigger ensures the workflow runs with proper permissions while maintaining security by executing the workflow file from the base branch rather than the potentially untrusted PR branch.

Assumption 2: Security considerations when using pull_request_target

Options Considered:

• Check out PR code to analyze
• Only use the PR metadata without checking out code

Chosen Option: Only use PR metadata without checking out code

Rationale: The LinkBot workflow doesn't need to check out or execute any code from the PR—it only reads the PR body text to check for issue links and posts a comment if needed. This aligns with security best practices for pull_request_target workflows and matches the pattern used by other bot workflows in the repository.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Update Workflow Trigger Configuration

Modify the workflow to use the appropriate trigger that provides write access for PRs from forks while maintaining security.

Change trigger from pull_request to pull_request_target

Update .github/workflows/pr-missing-linked-issue.yml to resolve the permission issue for fork PRs.

• Change the workflow trigger from pull_request to pull_request_target while keeping the same event types (opened, edited, reopened)
• Remove the explicit actions/checkout step if present, since LinkBot only needs PR metadata from the API and doesn't need to check out code (security best practice)
• Verify that the existing permissions block (pull-requests: write, contents: read) remains in place
• Add a comment in the workflow file explaining why pull_request_target is required (to enable commenting on PRs from forks)

🤖 Prompt for AI agents

Update the LinkBot workflow to fix the 403 permission error when commenting on
PRs from forks.

In `.github/workflows/pr-missing-linked-issue.yml`:
- Replace the `pull_request` trigger with `pull_request_target` (keep event
types: opened, edited, reopened)
- Remove any `actions/checkout` step if present
- Ensure permissions block includes `pull-requests: write` and `contents: read`
- Add a comment explaining that `pull_request_target` enables commenting on
forked PRs

Phase 2: Add Error Handling to Script

Enhance the JavaScript script with proper error handling to align with patterns used in other repository scripts and provide better debugging information.

Add try-catch blocks around API calls

Update .github/scripts/pr_missing_linked_issue.js to handle API errors gracefully.

• Wrap the github.rest.issues.listComments() call in a try-catch block with error logging
• Wrap the github.rest.issues.createComment() call in a try-catch block with error logging
• Log success messages when comments are posted successfully
• Return appropriate success/failure status from the script function
• Follow the error handling pattern established in other scripts like gfi_notify_team.js and p0_issues_notify_team.js

🤖 Prompt for AI agents

Add robust error handling to the LinkBot script following the repository's
established patterns.

In `.github/scripts/pr_missing_linked_issue.js`:
- Wrap `github.rest.issues.listComments()` in try-catch with error logging
- Wrap `github.rest.issues.createComment()` in try-catch with error logging
- Add success log messages after successful comment posts
- Return success/failure status from the script
- Follow error handling patterns from `gfi_notify_team.js` and
`p0_issues_notify_team.js`

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Update the LinkBot workflow to fix the 403 permission error when commenting on
PRs from forks.

In `.github/workflows/pr-missing-linked-issue.yml`:
- Replace the `pull_request` trigger with `pull_request_target` (keep event
types: opened, edited, reopened)
- Remove any `actions/checkout` step if present
- Ensure permissions block includes `pull-requests: write` and `contents: read`
- Add a comment explaining that `pull_request_target` enables commenting on
forked PRs
===============================================================================

Task: 2

Add robust error handling to the LinkBot script following the repository's
established patterns.

In `.github/scripts/pr_missing_linked_issue.js`:
- Wrap `github.rest.issues.listComments()` in try-catch with error logging
- Wrap `github.rest.issues.createComment()` in try-catch with error logging
- Add success log messages after successful comment posts
- Return success/failure status from the script
- Follow error handling patterns from `gfi_notify_team.js` and
`p0_issues_notify_team.js`

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord or schedule a call!

[sarthak-cs]

I ran into the same issue when opening a PR.
It looks like LinkBot is failing because the workflow token doesn’t have permission to comment on issues.
Adding issues: write under permissions in .github/workflows/pr-missing-linked-issue.yml should fix the 403 error.
can I submit a PR?

[exploreriii]

Hi @sarthak-cs
I think we might have to research more how github treats

permissions:
pull-requests: write <-- already has write permissions
contents: read

in the context of a fork PR to the base repo
You are right, it doesn't end up having the right permissions, but not yetsure of the solution

Assigned!

https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target

[sarthak-cs]

Thanks for assigning me!
I’ve looked into the issue and confirmed that fork PRs don’t get the same permissions as the base repo. Even with issues: write, the workflow token from a fork cannot comment on issues in the main repo, which is why we see the 403 error.

From my research, using pull_request_target in the workflow would allow the correct permissions.

However, this runs the workflow in the context of the base repo, so any code from the fork would have access to full repository permissions. This is why maintainers need to handle it carefully, to avoid accidentally letting untrusted code modify the main repo.

[exploreriii]

As discussed here, one way of approaching this could be to set it as a cron job that runs e.g. twice a day or something
#1125
this avoids permission issues entirely

[sarthak-cs]

From what I understand, resolving this would require either switching to a pull_request_target workflow (with careful security handling) or moving the logic to a scheduled (cron-based) workflow that runs in the base repo context, as discussed in #1125.

Since both approaches require changes and testing in the base repository, I don’t think I can safely implement or test the final fix from a fork alone. Happy to help with further investigation or review if needed.

[exploreriii]

What we have done is you can test it on a fork, if you are cron..we have a guide in/training
Other workflows also allow for a DRY_RUN=true and this only logs, rather than posts. combined with a workflow dispatch

[sarthak-cs]

I’ve explored this issue and tried implementing a fork-safe workflow in DRY_RUN mode.
After working on it, I realize that completing the fix requires more experience than I currently have.
I apologize for not being able to finish it, but I’m happy to continue helping with research, reviewing changes or testing where I can.