Workflows getting canceled instead of waiting/pending

[thijswassenaar]

Description

Hi,

I'm trying currently facing an issue where i try to bulk some actions.
Actions are created but instantly canceled. the last one create will run.
i use the following api :

api/v1/repos/test/netbox-automation/actions/workflows/file.yaml/dispatches

with the following api calls:

{
    "ref": "master", 
    "inputs": {
      "name": dev_name,
      "ip":  ip_address,
      "port": port
    }
  }

This is my workflow:

name: NetBox - Add Device
run-name: "NetBox Add: ${{ inputs.name }} (${{ inputs.ip }}) - ${{ github.workflow }}"
on:
  workflow_dispatch:
    inputs:
      name:
        description: 'Device Name'
        required: true
      ip:
        description: 'Device IP'
        required: true
      port:
        description: 'SSH Port'
        required: true
jobs:
  add_to_netbox:
    runs-on: debian-latest
    container:
      image: gitea.wassenaar.cloud/wilroffreitsma/netbox-automation/netbox-runner:latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Run NetBox Add Device
        env:
          NETBOX_URL: ${{ secrets.NETBOX_URL }}
          NETBOX_TOKEN: ${{ secrets.NETBOX_TOKEN }}
          DEV_NAME: ${{ github.event.inputs.name }}
          DEV_IP: ${{ github.event.inputs.ip }}
          DEV_PORT: ${{ github.event.inputs.port }}
        run: |
          # pynetbox is already pre-installed in the image!
          python3 netbox_scripts/add_device.py

result:

Gitea Version

1.25.5

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Docker Container

Database

None

[majiayu000]

Hi, I've been looking into this and traced the root cause.

Proposed approach: Investigate services/actions/ concurrency scheduling logic. PR #32751 added concurrency syntax support (merged Dec 2024) — the bug is likely that workflow_dispatch runs are being assigned a default concurrency group (e.g. keyed on workflow name + ref) with cancel-in-progress semantics even when no explicit 'concurrency' key is present in the YAML. Fix should ensure that without an explicit concurrency block, rapidly dispatched runs are queued as pending rather than canceled. Key files to examine: services/actions/schedule.go or equivalent concurrency manager, and the workflow_dispatch API handler.

I'll open a draft PR shortly. Happy to adjust based on your preference.

[carllapierre]

I've coincidentally run into this exact issue today as well! Glad I'm not crazy.

[lunny]

Do you know how to reproduce the issue?

[carllapierre]

@lunny , @thijswassenaar gives the right steps to reproduce above. I use the same dispatches api to send out multiple jobs for an ETL simultaneously (fan-out), only the last job in the queue is processed and all the other ones get cancelled as they use the same ref it seems.

[Zettat123]

For Gitea v1.25, since the concurrency syntax is not supported, triggering a workflow run will cancel previous jobs.

gitea/services/actions/workflow.go

Lines 190 to 199 in af29b81

	// cancel running jobs of the same workflow
	if err := CancelPreviousJobs(
	ctx,
	run.RepoID,
	run.Ref,
	run.WorkflowID,
	run.Event,
	); err != nil {
	log.Error("CancelRunningJobs: %v", err)
	}

Support for concurrency will be introduced in v1.26, which will resolve this bug.

[techknowlogick]

Yup, this behaviour will change to what you expect in 1.26. If you want to try out the 1.26 nightly, please do (take a backup first, and be aware there are migrations so you can't downgrade)

[fbrier]

Until 1.26 is released, what would be a safe delay in seconds between dispatching jobs? I have tried 30 seconds and the actions are still terminating even though they have different run-name(s). Is there another kind of workaround? Is the nightly build stable enough for use? Or could it corrupt repositories which would be my main concern. I do backup to the cloud every night. Oh, I just saw the comment about not being able to downgrade.

[fbrier]

I installed the nightly 1.26 build. Works great - no problems so far . Thank you.

[wxiaoguang]

current nightly (will be 1.26):

• https://dl.gitea.com/gitea/main-nightly/
• https://hub.docker.com/r/gitea/gitea/tags?name=main-nightly