Sticky PR comment step times out connecting to forge.wynning.tech #104

New issue

Closed

opened 2026-06-18 12:10:06 +00:00 by james · 0 comments

james commented

2026-06-18 12:10:06 +00:00

Owner

First post-#68 PR run hit a connect timeout in the OSV scanner's Post sticky PR comment step:

ConnectTimeoutError: Connect Timeout Error
  attempted addresses: 104.21.38.184:443, 2606:4700:3032::ac43:895b:443, 172.67.137.91:443
  timeout: 10000ms
  code: UND_ERR_CONNECT_TIMEOUT

104.21.* and 172.67.* are well-known Cloudflare anycast ranges, and 2606:4700::/32 is Cloudflare's IPv6 block. The runner is trying to reach forge.wynning.tech (CF-fronted) and the connection never completes — same network-topology issue we hit in #75 for the registry push, where the runner is inside the network and can't hairpin back through CF to its own server.

Run that produced the error: https://forge.wynning.tech/james/carol/actions/runs/126/jobs/7/attempt/1.

This isn't a payload-size issue (the API calls are small JSON, well under any CF body limit). It's a reachability issue — the runner physically cannot establish a TLS handshake to the CF edge.

Why the release workflow's similar curl-to-API call hasn't failed

release.yml's "Create Forgejo release" step uses curl and reaches the same forge.wynning.tech API. It's been succeeding on every tag push so far. Plausible explanations: different default timeouts, route luck, or this is also flaky and we just haven't caught it yet. Worth fixing release.yml the same way to be safe, but the urgent fix is the scanner steps that just regressed.

Fix

Mirror the PUSH_REGISTRY / PUBLIC_REGISTRY split from #76:

Introduce a FORGEJO_API_URL env var that scripts/ci/post-pr-comment.mjs prefers over GITHUB_SERVER_URL. Falls back to GITHUB_SERVER_URL so a self-hoster forking this workflow into a non-CF environment doesn't have to set it.
Add FORGEJO_API_URL: https://forge.int.wynning.tech to each scanner's Post sticky PR comment step env block in pr.yml (three steps) and secrets.yml (one step).
Same env var added to release.yml's "Create Forgejo release" step, preemptively.
Document the env var in docs/ci.md "Sticky PR comments" → "Required token scope" section (alongside the existing token-scope note).

Acceptance criteria

Next PR run's Post sticky PR comment step completes without a connect timeout.
If a scanner has qualifying findings, a comment lands on the PR; if clean, no comment posted; if findings cleared from a prior run, the stale comment is deleted (full #68 acceptance criteria still hold).
release.yml's next tag push hits the API via the internal URL too (preemptive).
docs/ci.md mentions the FORGEJO_API_URL override and explains when a self-hoster would set it (CF or other reverse-proxy-fronted Forgejo deployments where the runner can't reach the public URL).

Part of epic #2. Follow-up from #68, mirrors #75.

First post-#68 PR run hit a connect timeout in the OSV scanner's `Post sticky PR comment` step: ``` ConnectTimeoutError: Connect Timeout Error attempted addresses: 104.21.38.184:443, 2606:4700:3032::ac43:895b:443, 172.67.137.91:443 timeout: 10000ms code: UND_ERR_CONNECT_TIMEOUT ``` `104.21.*` and `172.67.*` are well-known Cloudflare anycast ranges, and `2606:4700::/32` is Cloudflare's IPv6 block. The runner is trying to reach `forge.wynning.tech` (CF-fronted) and the connection never completes — same network-topology issue we hit in #75 for the registry push, where the runner is inside the network and can't hairpin back through CF to its own server. Run that produced the error: <https://forge.wynning.tech/james/carol/actions/runs/126/jobs/7/attempt/1>. This isn't a payload-size issue (the API calls are small JSON, well under any CF body limit). It's a *reachability* issue — the runner physically cannot establish a TLS handshake to the CF edge. ## Why the release workflow's similar curl-to-API call hasn't failed `release.yml`'s "Create Forgejo release" step uses `curl` and reaches the same `forge.wynning.tech` API. It's been succeeding on every tag push so far. Plausible explanations: different default timeouts, route luck, or this is also flaky and we just haven't caught it yet. Worth fixing release.yml the same way to be safe, but the urgent fix is the scanner steps that just regressed. ## Fix Mirror the `PUSH_REGISTRY` / `PUBLIC_REGISTRY` split from #76: - Introduce a `FORGEJO_API_URL` env var that `scripts/ci/post-pr-comment.mjs` prefers over `GITHUB_SERVER_URL`. Falls back to `GITHUB_SERVER_URL` so a self-hoster forking this workflow into a non-CF environment doesn't have to set it. - Add `FORGEJO_API_URL: https://forge.int.wynning.tech` to each scanner's `Post sticky PR comment` step env block in `pr.yml` (three steps) and `secrets.yml` (one step). - Same env var added to `release.yml`'s "Create Forgejo release" step, preemptively. - Document the env var in `docs/ci.md` "Sticky PR comments" → "Required token scope" section (alongside the existing token-scope note). ## Acceptance criteria - [ ] Next PR run's `Post sticky PR comment` step completes without a connect timeout. - [ ] If a scanner has qualifying findings, a comment lands on the PR; if clean, no comment posted; if findings cleared from a prior run, the stale comment is deleted (full #68 acceptance criteria still hold). - [ ] `release.yml`'s next tag push hits the API via the internal URL too (preemptive). - [ ] `docs/ci.md` mentions the `FORGEJO_API_URL` override and explains when a self-hoster would set it (CF or other reverse-proxy-fronted Forgejo deployments where the runner can't reach the public URL). Part of epic #2. Follow-up from #68, mirrors #75.

james referenced this issue from a commit

2026-06-18 12:22:45 +00:00

fix(ci): route scanner-comment API calls via internal Forgejo URL (#104)

james added the

area:ci

label

2026-06-18 12:23:00 +00:00

james referenced this issue from a pull request that will close it,

2026-06-18 12:24:08 +00:00

fix(ci): route scanner-comment API calls via internal Forgejo URL (#104) #107

james closed this issue

2026-06-18 12:34:09 +00:00