[laxmareddyp]

GitHub event payloads only report author_association: "MEMBER" when a user's organization membership is public. Private keras-team members whose access comes through the organization or a team (rather than a direct repository collaborator entry) are reported as CONTRIBUTOR in the pull_request_target payload and get caught by the approved-issue check.

This adds a collaborator check via github.rest.repos.checkCollaborator inside scripts/pr-approved-issue.js. The endpoint returns 204 for every organization member, team member, and direct collaborator regardless of role (admin, maintain, write, triage, or org-default read) or membership visibility, and 404 for external contributors. Lookup errors log a warning and fail closed so external PRs are still checked.

[hertschuh]

I don't understand what's going on with { owner, repo, username } here.

Shouldn't it be something like { "owner": owner, "repo": repo, "username": username} ?

[laxmareddyp]

That is ES2015 shorthand property syntax, { owner, repo, username } is identical to { owner: owner, repo: repo, username: username }. It is the same form this file already uses for issues.get({ owner, repo, issue_number: number }) a bit above, and the test mock destructures username from it, so the key is set.

[laxmareddyp]

Once this is merged I will open a PR in keras-hub bumping the pull-request-validation.yml pin to the new commit. After that bump lands, could you open a small PR in keras-hub without a linked issue? The bump PR itself will not exercise the change because pull_request_target runs the workflow from the base branch, so yours would be the first one to hit the new code and confirm a private org member's PR stays open instead of going to draft.