This issue was identified and reported by gpt-5.6-sol. I independently
validated it using the reproduction below.
Bug
In v4.1 (5d8df5979747514c914e1c5a12335a7cf9a2745f), post_comment
resolves GITHUB_PR_RUN_ID to an owner/head branch, then selects a matching PR
instead of using the PR associated with the workflow run.
When one head branch has PRs against multiple bases, the artifact can be posted
to the wrong PR.
Reproduction
https://github.com/KSmanis/python-coverage-comment-action-wrong-pr-repro
PR #1's producer run
automatically triggered this
workflow_run,
which resolved PR #2. The resulting comment on PR #2 says
Generated for PR #1.
Expected
Post to the PR associated with the workflow run, or fail when ambiguous.
Suggested fix
Use the workflow run's associated PR, with branch lookup only as a fallback.
Bug
In v4.1 (
5d8df5979747514c914e1c5a12335a7cf9a2745f),post_commentresolves
GITHUB_PR_RUN_IDto an owner/head branch, then selects a matching PRinstead of using the PR associated with the workflow run.
When one head branch has PRs against multiple bases, the artifact can be posted
to the wrong PR.
Reproduction
https://github.com/KSmanis/python-coverage-comment-action-wrong-pr-repro
PR #1's producer run
automatically triggered this
workflow_run,which resolved PR #2. The resulting comment on PR #2 says
Generated for PR #1.Expected
Post to the PR associated with the workflow run, or fail when ambiguous.
Suggested fix
Use the workflow run's associated PR, with branch lookup only as a fallback.