eho/register-referentie
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

verify-stack stuck in "waiting", never dispatched, after Gitea 1.27 + act_runner 2.0.0 upgrade #134

New Issue
Closed
opened 2026-07-24 11:30:22 +00:00 by not · 0 comments
not commented 2026-07-24 11:30:22 +00:00
Contributor
Copy Link
Copy Source

Symptom

Since upgrading to Gitea 1.27.0 + act_runner 2.0.0, the verify-stack job never starts. The workflow run sits in state waiting indefinitely; verify-stack has no logs (never dispatched to a runner). The other five jobs (lint, build, unit, frontend, mutation) complete normally, so main stays perpetually pending/red (P0).

Observed on the #133 merge run (run 582 / #170 on main): 5 jobs success, verify-stack waiting, run status: waiting.

Root cause

verify-stack is the only job gated by a status-function if on top of needs:

verify-stack:
  needs: [mutation]
  if: ${{ !cancelled() }}

Gitea 1.27 reworked exactly this construct — jobs whose gate uses always()/cancelled() now route through a new transitional Cancelling job state + server↔runner capability negotiation ("Requires Gitea Runner 2.0.0"), and needs/continue-on-error aggregation changed. On this 1.27 + 2.0.0 pairing that handshake does not resolve for our job, so it never leaves waiting. Plain jobs (no if/needs) are unaffected — matching the observed pattern. It worked pre-upgrade (run 169, old runner).

Related upstream: go-gitea/gitea#31074, #27116, #35782; forum "jobs stuck in waiting indefinitely".

Fix

Drop if: ${{ !cancelled() }} from verify-stack, keep needs: [mutation] (default if: success() dispatches normally and still serialises the two heavy jobs — OOM avoidance, #126). The !cancelled() was added in #127 so verify-stack runs even when the mutation ratchet fails; the accepted trade-off is that a mutation failure now skips verify-stack (fix + re-push exercises it on the re-run). Document the cause in docs/runbooks/gitea-actions-gotchas.md.

Also: the stuck run must be (force-)cancelled from the UI; it will not clear itself (cf. #35782).

## Symptom Since upgrading to **Gitea 1.27.0** + **act_runner 2.0.0**, the `verify-stack` job never starts. The workflow run sits in state `waiting` indefinitely; `verify-stack` has **no logs** (never dispatched to a runner). The other five jobs (`lint`, `build`, `unit`, `frontend`, `mutation`) complete normally, so `main` stays perpetually pending/red (P0). Observed on the `#133` merge run (run 582 / #170 on `main`): 5 jobs `success`, `verify-stack` `waiting`, run `status: waiting`. ## Root cause `verify-stack` is the only job gated by a **status-function `if`** on top of `needs`: ```yaml verify-stack: needs: [mutation] if: ${{ !cancelled() }} ``` Gitea 1.27 reworked exactly this construct — jobs whose gate uses `always()`/`cancelled()` now route through a new **transitional `Cancelling` job state + server↔runner capability negotiation** ("Requires Gitea Runner 2.0.0"), and `needs`/`continue-on-error` aggregation changed. On this 1.27 + 2.0.0 pairing that handshake does not resolve for our job, so it never leaves `waiting`. Plain jobs (no `if`/`needs`) are unaffected — matching the observed pattern. It worked pre-upgrade (run 169, old runner). Related upstream: go-gitea/gitea#31074, #27116, #35782; forum "jobs stuck in waiting indefinitely". ## Fix Drop `if: ${{ !cancelled() }}` from `verify-stack`, keep `needs: [mutation]` (default `if: success()` dispatches normally and still serialises the two heavy jobs — OOM avoidance, #126). The `!cancelled()` was added in #127 so verify-stack runs even when the mutation ratchet fails; the accepted trade-off is that a mutation failure now skips verify-stack (fix + re-push exercises it on the re-run). Document the cause in `docs/runbooks/gitea-actions-gotchas.md`. Also: the stuck run must be (force-)cancelled from the UI; it will not clear itself (cf. #35782).
not added the type:bugarea:infra labels 2026-07-24 11:30:22 +00:00
not closed this issue 2026-07-24 11:59:29 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:acl
area:bff
area:docs
area:domain
area:event-subscriber
area:infra
area:portal-behandel
area:portal-beheer
area:portal-openbaar
area:portal-self-service
area:projection
area:workflow
type:adr-proposal
type:bug
type:chore
type:slice
No labels area:infra type:bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
eho (Edwin van den Houdt)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eho/register-referentie#134