Skip to content

/actions/tasks API endpoint doesn't show workflows that are “Waiting” #35134

@Strangersknowme

Description

@Strangersknowme

Description

Here's what's happening:

Let's say I have only 1 runner registered. If I push a commit to a repo that triggers 2 workflows, one grabs the runner and shows as “running” in the UI, the other shows as Waiting, cool. But here comes the problem.

The Problem

When I poll the /repos/{owner}/{repo}/actions/tasks endpoint, I get back the response JSON with fields workflow_runs and total_count, but only the running one is in workflow_runs array meaning there is no mention of the workflow that is showing as waiting in the web UI. The one that’s showing as waiting in the web UI isn’t in the list at all until a runner frees up and it actually starts, then it shows up as "status": "running".

Also, this doesn't only happen on new workflow when you commit (or whatever way your trigger a workflow) but all workflows, like if you re-run a workflow, it doesn't show in the response until it starts actually running when a runner becomes available.

The tasks endpoint is supposed to schedule and track workflows atleast that's how I see it, to enqueue workflows. It should list all workflows that need to run (with a waiting status), not just the ones currently executing.

How I’d expect it to work

  1. I GET /actions/tasks
  2. Response includes every triggered workflow, each with:
    • "status": "waiting" if no runner is available
    • "status": "running" once a runner picks it up
    • "status": "success"/"cancelled"/"failure" as usual afterward

How to reproduce

  1. Register ** any number of runners less than the number of workflows triggered** on a repo.
  2. Push a commit that triggers those n Actions workflows.
  3. Immediately GET /actions/tasks endpoint.
  4. Observe that only those workflow in the JSON which are actually running and no mention of those which are showing as Waiting in the web UI.

Possible fix

When scheduling tasks, add every workflow to the queue with a waiting status. Then flip to running as soon as a runner picks it up. Failure and cancellation already work fine.

Why it matters

I’ve got one central CI repo dispatching builds to a bunch of child repos. I rely on /actions/tasks to track each child workflow’s status. Right now, if a child is waiting for a runner, it never shows up in the API call and my orchestration pipeline totally breaks.

Let me know if something isn't clear.

Gitea Version

1.24.2

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Ubuntu 24.04.2 LTS

How are you running Gitea?

Running Gitea rootless in docker using the official gitea image gitea/gitea:1.24.2-rootless.

Database

SQLite

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions