Repository navigation
[Bug]: Forgejo PR watch stays stuck after required checks pass because an optional check remains failed #18770
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 with required CI checks.
- On a PR head, let a separate, non-required check fail.
- Ask the agent to watch the PR using
watch_pull_request. - Let every required check pass, leaving the optional check failed.
- Wait for the agent to resume.
Expected behavior
The watcher wakes the agent when all required checks pass. The optional failure remains visible but does not block that notification.
Actual behavior
Source inspection found that forgejoChecks does not populate required metadata. evaluatePullRequestWatch falls back to requiring every reported check to pass when none are marked required. Therefore, the non-required failure prevents the completion notification.
Relevant files:
packages/source-control-forgejo/src/server/forgejoPullRequestJson.tsapps/server/src/orchestration-v2/pullRequestWatch.ts
The same logic is present on upstream main at 0e7346ccd9427c06161e222319e718e6bd70887f.
Related: #16575 concerns skipped jobs being mapped to pending. This case involves an actual non-required failure, with no skipped jobs.
Impact
Major degradation or frequent failure
Version or commit
0.0.46-nightly.20261011.2994
Environment
Linux aarch64, T3 Code with the Codex provider, self-hosted Forgejo.
Logs or stack traces
Sanitized status summary for the same PR head:
Non-required earlier review workflow: failure
Required static checks: success
Required review job: success
Required published review approval: success
Required integration tests: success
Required final CI gate: success
CI completed successfully at 19:57 UTC on 2026-10-12.
After completion, list_thread_pull_requests still returned watching: true.
Manual intervention led to a successful checked merge at 20:14 UTC.Screenshots, recordings, or supporting files
No response
Workaround
Manually prompt the agent to check current required-check results and run the repository’s normal merge checks. This allowed the merge without bypassing protections.
Activity
juliusmarminge commentedon Oct 12, 2026
Note
Grok responding on behalf of Julius.
Thanks. I confirmed this on main:
forgejoChecks(packages/source-control-forgejo/src/server/forgejoPullRequestJson.ts) maps commit statuses to checks but never setsrequired.evaluatePullRequestWatch(apps/server/src/orchestration-v2/pullRequestWatch.ts) gates "passed" on the required checks, or on every check when none are marked required. The fallback is intentional for hosts that don't report required checks. Forgejo does report them, though: branch protection hasenable_status_checkandstatus_check_contexts, which are glob patterns. Because we never read them, one failing optional status blocks the wake on Forgejo.I'm accepting this as a bug. The fix is to load the base branch's protection rule, match
status_check_contextsagainst status contexts (with glob support), and setrequired: trueon the matches. One caveat: Forgejo may only return branch protection to tokens with repo admin rights. If the read fails, the watch should keep the current all-checks behavior.This isn't a duplicate of #16575 (skipped jobs mapped to pending), and neither open PR fixes it: #16668 handles skipped jobs and #18119 handles finish-time wakes, and neither sets
requiredfor Forgejo. Until it's fixed, the workaround is what you already did: ask the agent to re-check the required statuses by hand.