Welcome / run (pull_request_target) keeps failing

[DannyvdSluijs]

See https://github.com/jsonrainbow/json-schema/actions/runs/31494331864/job/93788165915?pr=932

2026-08-11T13:04:44.0840496Z Current runner version: '2.336.0'
2026-08-11T13:04:44.0865717Z ##[group]Runner Image Provisioner
2026-08-11T13:04:44.0866663Z Hosted Compute Agent
2026-08-11T13:04:44.0867248Z Version: 20260707.563
2026-08-11T13:04:44.0867859Z Commit: 02667638d2b423fbc733a8e32a88b44996a3ba6e
2026-08-11T13:04:44.0868646Z Build Date: 2026-07-07T19:33:50Z
2026-08-11T13:04:44.0869353Z Worker ID: {62a1174d-4653-47c7-84aa-7569af7bb7ff}
2026-08-11T13:04:44.0870086Z Azure Region: westus
2026-08-11T13:04:44.0870662Z ##[endgroup]
2026-08-11T13:04:44.0872649Z ##[group]Operating System
2026-08-11T13:04:44.0873384Z Ubuntu
2026-08-11T13:04:44.0873937Z 24.04.4
2026-08-11T13:04:44.0874425Z LTS
2026-08-11T13:04:44.0875073Z ##[endgroup]
2026-08-11T13:04:44.0875616Z ##[group]Runner Image
2026-08-11T13:04:44.0876257Z Image: ubuntu-24.04
2026-08-11T13:04:44.0876836Z Version: 20260720.247.2
2026-08-11T13:04:44.0878158Z Included Software: https://github.com/actions/runner-images/blob/ubuntu24/20260720.247/images/ubuntu/Ubuntu2404-Readme.md
2026-08-11T13:04:44.0879695Z Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260720.247
2026-08-11T13:04:44.0880703Z ##[endgroup]
2026-08-11T13:04:44.0882255Z ##[group]GITHUB_TOKEN Permissions
2026-08-11T13:04:44.0884180Z Issues: write
2026-08-11T13:04:44.0884794Z Metadata: read
2026-08-11T13:04:44.0885349Z PullRequests: write
2026-08-11T13:04:44.0886006Z ##[endgroup]
2026-08-11T13:04:44.0888120Z Secret source: Actions
2026-08-11T13:04:44.0889259Z Prepare workflow directory
2026-08-11T13:04:44.1224744Z Prepare all required actions
2026-08-11T13:04:44.1278193Z Getting action download info
2026-08-11T13:04:44.5127827Z Download action repository 'wow-actions/welcome@v1' (SHA:68019c2c271561f63162fea75bb7707ef8a02c85)
2026-08-11T13:04:45.1055749Z Complete job name: run
2026-08-11T13:04:45.1790369Z Node 20 is being deprecated. This workflow is running with Node 24 by default. If you need to temporarily use Node 20, you can set the ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true environment variable. For more information see: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
2026-08-11T13:04:45.1799492Z ##[group]Run wow-actions/welcome@v1
2026-08-11T13:04:45.1800255Z with:
2026-08-11T13:04:45.1802105Z   FIRST_ISSUE: 🚀 @{{ author }}, thanks for your contribution! Every idea, bug report, and discussion helps make this project better. Your input is invaluable, and we appreciate the time you took to share it. A maintainer will review it soon—stay awesome! 💡✨

2026-08-11T13:04:45.1804651Z   FIRST_PR: 🎉 You're making a difference! We appreciate your effort and dedication. A reviewer will check it out soon, but in the meantime, give yourself a pat on the back. Keep up the great work! 💪🚀

2026-08-11T13:04:45.1807220Z   FIRST_PR_MERGED: 💖 Welcome @{{ author }} as first-time contributor! Your efforts matter, and we’re so grateful for your contribution. Open source thrives because of people like you. Keep going, keep learning, and know that your work is truly valued. 🌱✨

2026-08-11T13:04:45.1809870Z   STAR_MESSAGE: ⭐ Enjoying contributing? Star the project! ⭐Your contributions help this project grow, and we'd love your support in another way too! If you find this repo helpful, consider leaving a star 🌟 on GitHub.

2026-08-11T13:04:45.1814749Z   GITHUB_TOKEN: ***
2026-08-11T13:04:45.1815526Z ##[endgroup]
2026-08-11T13:04:45.2636996Z (node:2153) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
2026-08-11T13:04:45.2638334Z (Use `node --trace-deprecation ...` to show where the warning was created)
2026-08-11T13:04:45.2767243Z (node:2153) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities.
2026-08-11T13:04:45.9994684Z ##[error]HttpError: Resource not accessible by integration
2026-08-11T13:04:46.0062844Z ##[error]Resource not accessible by integration
2026-08-11T13:04:46.0237726Z Cleaning up orphan processes
2026-08-11T13:04:46.0719403Z ##[warning]Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: wow-actions/welcome@v1. For more information see: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/

[Amoifr]

Some evidence that narrows this down, gathered while my own pull request tripped it.

The run history splits cleanly by where the head branch lives:

Date	Head repository	Result
2026-08-21 (×5)	jsonrainbow/json-schema	success
2026-08-21	zoliszabo/json-schema	failure
2026-08-22	UmairRathore/json-schema	failure
2026-08-30	Amoifr/json-schema	failure
2026-08-30	Amoifr/json-schema	success

That last pair is the interesting one, and I think it rules out the fork itself as the cause. Both are mine, opened minutes apart from the same fork, same event, same workflow file. The only thing separating them is that #941 was my first pull request here, so the action had a welcome comment to post, while by the time #942 opened, the search found #941 and the action had nothing to do.

Which fits the rest of the table: every green run is one where the action had nothing to post, because the author was a maintainer opening from the base repository. And consistent with that, there is no github-actions[bot] comment among the 50 most recent issue comments in this repository, so the welcome message does not appear to have been landing for anyone.

So the failing path looks like the one that actually writes, rather than pull_request_target as such, which would also explain why it never shows up on your own pull requests. On that path wow-actions/welcome calls search.issuesAndPullRequests, issues.createComment and, since STAR_MESSAGE is configured, GET /repos/{owner}/{repo}/stargazers.

I have not been able to pin which of those three is refused, since that needs a run in this repository rather than reading the action's source, so please take the last paragraph as a lead rather than a conclusion.

I left welcome.yml untouched in #941 for this reason: its permissions look too narrow rather than too wide, and tightening it further would have been the wrong direction.

[DannyvdSluijs]

Root cause: the STAR_MESSAGE star-check calls an endpoint GitHub restricted in July 2026

TL;DR — this is not a token or permissions problem on our side. The workflow already runs on pull_request_target and already receives a write token. The action fails inside getComment(), on GET /repos/{owner}/{repo}/stargazers, which GitHub limited to admins and collaborators in July 2026. Removing the STAR_MESSAGE input fixes it with no token, PAT, or permission changes.

It is not a permissions problem

The failing run's own log shows the token has everything the action needs:

##[group]GITHUB_TOKEN Permissions
Issues: write
Metadata: read
PullRequests: write
##[endgroup]
Secret source: Actions

Worth contrasting with the Update Changelog failure, which was a permissions problem (Contents: read, Secret source: None, fixed by switching that workflow to pull_request_target). Same 403-shaped symptom, unrelated cause — the fix there does not apply here.

Only first-time-contributor runs fail

In wow-actions/welcome at the commit v1 pins (68019c2), src/index.ts calls issues.listForRepo and bails unless list.length === 1. Only then does it call getComment(), which — because we set STAR_MESSAGE — calls isStarredBy() in src/util.ts, and that requests GET /repos/{owner}/{repo}/stargazers.

So the failure should occur only on a contributor's first PR, and never otherwise. Our run history matches exactly:

Run	PR	Author	Result
08-11	#932	zoliszabo — 1st PR	failure
08-11	#934	zoliszabo — 2nd PR	success
08-30 09:23	#941	Amoifr — 1st PR	failure
08-30 09:32 – 10:07	#942, #943, #944	Amoifr — 2nd–4th PR	success
08-22, 09-04	#940	UmairRathore — only PR	failure ×2

Every failure is a first contribution; every success is a run the action abandons before it touches the restricted endpoint. This also rules out listForRepo and the token scopes — the successful runs exercise both.

What changed

From the starring API docs:

In July 2026, to ensure responsible use of this data and to protect users from misuse, we are introducing new access restrictions to the endpoints related to starring. Access to the stargazers listing endpoints will be limited to admins and collaborators.

GITHUB_TOKEN is a GitHub App installation token — neither an admin nor a collaborator — which is precisely the condition that yields Resource not accessible by integration.

The timeline lines up:

• Last welcome comment successfully posted: Add missing ext-filter dependency #922 on 2026-07-02. Its body includes the star line, so isStarredBy() ran, returned false, and appended the message. The endpoint worked that day.
• Every run since has failed, without exception: 07-28, 08-06, 08-11, 08-18, 08-21, 08-22, 08-30, 09-01, 09-04.
• git log --follow .github/workflows/welcome.yml → last modified 2026-01-27 (Fix welcome workflow permission errors from forked PRs #875). Nothing on our side changed in the window where the behaviour broke.

One caveat: the log does not name the failing endpoint (ACTIONS_STEP_DEBUG was not enabled), so this is inference from the action's source, the failure pattern, and the documented restriction rather than a captured request. It is also self-confirming — see below.

Fix

Drop the STAR_MESSAGE input and fold that sentence into FIRST_ISSUE, FIRST_PR, and FIRST_PR_MERGED instead. getComment() only calls isStarredBy() when STAR_MESSAGE is non-empty, so the restricted endpoint is never reached. Contributors still see the star nudge — unconditionally, rather than only when they have not already starred, which is a fair trade for a working welcome message.

No PAT, no Actions-settings change, no bump of the pinned action needed.

This doubles as the confirmation: the next first-time-contributor PR either gets its comment, or the error moves to createComment and the diagnosis above is wrong.

Upstream status

wow-actions/welcome is effectively dormant — last commit and release 2024-10-18 (v1.3.1, which is what v1 resolves to), five open issues, one unreviewed PR. Nobody has reported the stargazers restriction upstream (a search for stargazers across the repo returns nothing), so there is no upstream fix to wait for and no existing issue to subscribe to. Worth filing one, but the local fix should not depend on it.

Other open upstream issues that affect us, for the record:

• #9 — the same Resource not accessible by integration error, open since 2022. Note that the historical cause discussed there (the pull_request → pull_request_target token difference) is not our cause; we already made that switch in Fix welcome workflow permission errors from forked PRs #875, and our log confirms the write token. Same error string, different origin.
• #16 / #17 — first-timer detection only reads the first page of listForRepo, so long-standing contributors are occasionally welcomed again. URI Resolver not resolving absolute file paths correctly #17 proposes using search total_count; unmerged since May 2026.
• #14 / #15 — the FIRST_PR_MERGED path uses the deprecated GET /search/issues, which already hard-fails for author:Copilot. This will break that path independently of the issue above.
• #11 — bot-authored PRs (e.g. Dependabot) fail user search for the same reason.

Given four open defects and no upstream maintenance in ~2 years, replacing this action with a small actions/github-script step is worth considering separately — the whole behaviour is two API calls and a conditional.