ci: predict-conflicts fails on pull_request_review for fork PRs with 'Resource not accessible by integration'

[thepastaclaw]

Summary

Check Potential Conflicts can fail on fork PRs when triggered by pull_request_review, even when the same head SHA already passed on pull_request_target and there are no predicted conflicts.

Example

PR: #7237
Head SHA: 84534b24709ccf165ab81525c4de58913d80d39f

Successful run on PR event:

• event: pull_request_target
• run: https://github.com/dashpay/dash/actions/runs/24064263962/job/70186734007
• result: success
• validate_conflicts reported no conflicts and Remove conflict comment if no conflicts succeeded

Failing run on review event for the same SHA:

• event: pull_request_review
• run: https://github.com/dashpay/dash/actions/runs/24064679172/job/70188073044
• result: failure
• validate_conflicts again reported no conflicts, but Remove conflict comment if no conflicts failed with:
  • Resource not accessible by integration

Root cause

This looks like a workflow permission/event mismatch, not a branch-specific code problem:

• PR backport: Bitcoin Core v0.26 backports (batch 1) #7237 is a cross-repository PR (thepastaclaw/dash -> dashpay/dash)
• .github/workflows/predict-conflicts.yml runs on both pull_request_target and pull_request_review
• On pull_request_review, the mshick/add-pr-comment@v2 step that updates the sticky comment can fail with Resource not accessible by integration
• The same workflow and same head SHA succeed on pull_request_target, so this is not caused by the PR contents

Reproduction

1. Open a cross-repo PR against dashpay/dash
2. Ensure Check Potential Conflicts reports no conflicts on the normal PR-triggered run
3. Submit a PR review
4. Observe the pull_request_review-triggered Check Potential Conflicts run fail in Remove conflict comment if no conflicts

Possible fixes

• Stop running this workflow on pull_request_review
• Or guard the comment-update steps so review-triggered runs don't fail the check when GitHub denies comment writes
• Or switch the review-triggered path to continue-on-error: true / permission-aware logic around mshick/add-pr-comment

[thepastaclaw]

New data point from PR #7237 on a newer head (c425124c7e57a3f5e851d9f5ceb8934d850e84ff):

• pull_request_target run still succeeds: https://github.com/dashpay/dash/actions/runs/24067647194
• pull_request_review run on the same head now completes as action_required with no jobs/check runs created: https://github.com/dashpay/dash/actions/runs/24067866018
• The corresponding check suites are action_required with latest_check_runs_count: 0 and no associated PR in the suite payload

This still points to the review-triggered workflow path itself, not PR content. It also looks repo-wide rather than branch-specific: recent predict-conflicts pull_request_review runs on other PR heads (for example kernel-zero-is-mn-sync and feat/qt-plus) are also ending in action_required.

So the failure mode seems to have broadened from the earlier Resource not accessible by integration case into a more general review-event workflow/approval problem.

[thepastaclaw]

Another confirming data point from #7173:

• failing run: https://github.com/dashpay/dash/actions/runs/23317191427
• event: pull_request_review
• PR head at failure: 711d85b7b4db6757a3db0e9fd2125b9c69809e34
• failing job: https://github.com/dashpay/dash/actions/runs/23317191427/job/68046942340
• failure mode: mshick/add-pr-comment@v2 ends with Resource not accessible by integration after the conflict scan itself finishes and reports Conflicting PRs: []

So this one was not caused by the fuzz-regression code changes themselves; the actual conflict prediction logic completed successfully and the failure happened in the review-triggered PR-comment write path.

For comparison, the same PR on the current head now has a green predict_conflicts run under pull_request_target:

• passing run: https://github.com/dashpay/dash/actions/runs/24381921280
• event: pull_request_target
• current PR head: dc5e9fe324b3f489f9cb1eb20a90dfb308b2c915

That lines up with this being the existing fork/review-event permissions problem tracked here, not an in-scope breakage in PR #7173.