[Bug]: Forgejo skipped status keeps watch_pull_request pending when no required-check policy is set
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 64/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- github, typescript
Research direction
Start with packages/source-control-forgejo/src/server/forgejoPullRequestJson.ts and trace how forgejoChecks maps Forgejo job states; then follow evaluatePullRequestWatch to see how those states affect the all-status gate. Compare the current behavior for the reported success, success, and skipped statuses with the expected result. Done means the watch reports all checks passed when jobs finish without failures, including when one is skipped.
Written by the indexing model from the issue text.
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Use a Forgejo repository whose base branch has no status-check policy (
enable_status_check: false, so no required contexts). - Add a workflow job that only runs on push, for example
deploy: { needs: test, if: github.event_name == 'push' }. - Open a pull request. Once CI finishes, the head commit reports:
AI Review / review (pull_request) success CI / test (pull_request) success CI / deploy (pull_request) skipped - Call
watch_pull_requestfor the pull request and let all jobs finish.
Expected behavior
The watch wakes the agent with "All 3 checks passed", because every job has finished and none failed.
Actual behavior
The watch never reports the passed checks. forgejoChecks in packages/source-control-forgejo/src/server/forgejoPullRequestJson.ts maps every state other than success, failure and error to pending, so the skipped job keeps the all-status gate open. In our case the watch stayed silent for almost six hours until we merged the pull request by hand.
This is the part of #16575 that its closing comment left open ("skipped statuses still block watches when required-check policy is absent"); the comment asked for a separate issue. #18775 covers branches with a required-check policy. #16668 already contains the fix for this case. Its description notes that no real Forgejo instance was used; this report confirms the failure on a live Forgejo 17.0.0 instance.
Impact
Major degradation or frequent failure
Every pull request in a repository with a push-only job hits this, so watch_pull_request cannot be used there.
Version or commit
0.1.2-nightly.20261021.3499 (already contains #18775)
Environment
T3 Code desktop nightly on macOS 27.0.1, Forgejo 17.0.0+gitea-1.22.0
Logs or stack traces
pull request watch ended {"reason":"merged","minutes":348,"quietMinutes":348,"wakes":0,"reads":172,"partial":false}
We also ran the installed nightly's bundled forgejoChecks and evaluatePullRequestWatch against the three statuses above:
- current mapping:
skippedbecomespending,passed: false, no change reported - with
skippedpreserved, as in #16668: the same evaluator reportschecks-passedwithcount: 3
Workaround
Required status checks on the base branch let the watch gate only on those (#18775), but that changes the merge policy, and a required context that never reports (for example a workflow with paths-ignore on a docs-only change) then blocks merging. We currently poll the Forgejo API from the agent instead of using watch_pull_request.
Investigated with an agent in T3 Code; the values above come from the live instance and the installed app bundle.
- Dominant language
- TypeScript
- Stars
- 24.8k
- Forks
- 6.4k
- Avg merge
- 2h 48m
- Merged PRs (30d)
- 353
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from pingdotgg/t3code
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Diff line counts use Indian numeral grouping on en_IN locale (inconsistent toLocaleString calls)Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
bug needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
All issues in pingdotgg/t3code
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 Under an hour Newbie friendliness 80/100
nuxt-content/nuxt-studio#599 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
hurttlocker/o8#4997 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
danielmiessler/LifeOS#2413 ·
Maintainers usually reply within 3 days
-
Plugin: sheet music can't be scrolled by hand before playbackPossibly taken @snakajima claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
receptron/jinglescript#51 ·
Maintainers usually reply within 1 day