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

[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

[ChristopherHX]

You are looking for these gitea 1.25-dev endpoints

• https://gitea.com/api/swagger#/repository/listWorkflowJobs
• https://gitea.com/api/swagger#/repository/getWorkflowRuns

Why this behavior?

• An ActionTask is created once a runner picks up a job
• An ActionJob is created at the beginning of a workflow

The newer jobs endpoint I contributed, are based on both ActionJob and ActionTask and also have webhooks you can listen for on every system/user/org/repo level.

---

Since you already have 1.24.2, you are already able to collect this information via workflow_job webhooks. The Rest endpoint are 1.25+ only.

---

I actually have no idea what to do about the existing tasks endpoint, the newer endpoints are based on GitHub Rest Api.

[ChristopherHX]

I just noticed that the workflow runs rest repo level swagger response is broken the expected workfow runs result is described in https://gitea.com/api/swagger#/organization/getOrgWorkflowRuns and I will look into correcting this for 1.25-dev

EDIT
I do not get it, only gitea.com is broken maybe somebody failed during merge of the modified version of Gitea

[Strangersknowme]

Since you already have 1.24.2, you are already able to collect this information via workflow_job webhooks

Won't I have to setup a seperate server for consuming this though? Like usually people use discord or telegram bots for this but that's only showing the status, I need it for tracking, that's why I was using the actions/tasks/ endpoint.

You said in 1.25-dev branch it is available as a REST endpoint, are there any breaking changes?

[ChristopherHX]

Won't I have to setup a seperate server for consuming this though? Like usually people use discord or telegram bots for this

Yes you would have to, can be a private sidecar container next to your gitea image additionally you would need to whitelist the webhook target depending on the configuration.

You said in 1.25-dev branch it is available as a REST endpoint, are there any breaking changes?

Yes there are very likely breaking changes, but they not necessary affect you.

I would always suggest you to do a full backup before trying out anything, even if you would still be able to downgrade nightly to 1.24.x (currently still uses the same database revision, actions concurrency not yet merged that breaks this).(downgrade no longer possible)

If you want a list of changes, then you would need to wait for 1.25-rc0.