Workflow Post-Run Steps Not Executed When Workflow is Cancelled

[bircni]

Description

When a workflow run is cancelled using the cancel button in the UI, the post-run cleanup steps (defined as post: in action metadata) are not executed. This is a significant issue because post-run steps are critical for:

• Resource cleanup (stopping containers, cleaning temporary files, releasing locks)
• Artifact publishing (uploading logs or reports even on cancellation)
• Notification systems (notifying external services that the workflow ended)
• State management (ensuring system consistency)

Current Behavior

1. User clicks "Cancel workflow run" button on the UI
2. The Cancel() handler in routers/web/repo/actions/view.go is invoked
3. actions_model.CancelJobs() is called, which immediately sets job status to StatusCancelled
4. The job is marked as done, and no post-run steps are executed
5. Cleanup tasks that should run are skipped entirely

Expected Behavior (GitHub Actions)

GitHub Actions always executes post-run steps, regardless of:

• Workflow cancellation (user clicked cancel button)
• Job failure
• Timeout
• Step failure

This ensures resource cleanup and notification always occur.

Steps to Reproduce

1. Create a workflow with at least one regular step and one post-run cleanup step
2. Start the workflow run
3. While the workflow is running, click the "Cancel" button
4. Observe that post-run steps do not execute (they are skipped entirely)
5. Resources that should be cleaned up remain uncleaned

Expected Result

Post-run steps should execute after cancellation, allowing proper cleanup before the job terminates.

Actual Result

Post-run steps are skipped when a workflow is cancelled, leaving resources in an inconsistent state.

Proposed Solution

Implement a state transition that allows post-run steps to execute even when a workflow is cancelled:

Running → Cancelling → PostRunning → Cancelled

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?

independent of running gitea

Database

None

[KalashThakare]

Hi @bircni , I would like to work on this issue.

[bircni]

Feel free but it's hard

[bircni]

@KalashThakare it needs some restructuring and thinking and fixes also to the act-runner
@ChristopherHX what do you think

[KalashThakare]

@bircni
Yeah for now I’m working on the Gitea side, trying to avoid the immediate hard transition to a terminal state and introducing a proper cancelling phase.

Haven’t dived into act_runner yet, but from what I’m seeing, even with the server-side fix, the runner might still be force-stopping execution and skipping cleanup.

I’ll explore the act_runner part next once I validate the changes on the Gitea side.

[KalashThakare]

Hi @bircni, I believe the issue is resolved now and meets the expected behavior. Before I open the PR in act_runner, could you please review the flow and let me know if any changes needed.

Screen.Recording.2026-04-18.014524.mp4

Summary of what was fixed in act_runner and gitea:

act_runner:

1. Updated cancellation handling in runner execution flow so cancel signals are handled explicitly while the executor is running.
2. On cancel, runner now attempts to stop the active task container(s) and then waits for executor finalization (instead of exiting early), so cleanup/finalization can complete.
3. Improved reporter finalization so final state/log updates are still flushed even when the original context is already canceled.
4. Improved cancellation polling/reporting so runner observes cancel transitions promptly and consistently.

gitea:

1. Added a transitional cancelling status in actions status model and status/result mapping.
2. Updated cancel flow to set jobs/tasks to cancelling first (instead of immediately final cancelled).
3. Updated task state update path to finalize cancelling -> cancelled when runner reports terminal state.
4. Updated runner UpdateTask API response to return cancellation signal while task is cancelling.
5. Updated run/job status aggregation to treat cancelling as an active transitional state.
6. Added/updated tests for status mapping and aggregation to cover cancelling.

Observed behavior now:

1. Without cancel: workflow behavior remains unchanged.
2. With cancel: running step is interrupted, remaining normal steps are skipped, cleanup path still executes, and final status becomes cancelled.

[bircni]

What about the post run steps of an action? Eg checkout or setup node have one

[bircni]

But Looks good!!!
Open a PR that's the more interesting part

Another point, what happens if one of these two don't support the cancel stuff yet?
Like gitea is 1.22 but Act Runner is with your fix
Or gitea is with your fix and Act Runner is not

[ChristopherHX]

I think this looks like a good plan to tackle this.

[bircni]

I also had something like this on disk for testing but did not have the time yet to complete, so very happy that @KalashThakare has a look and such a good approach

[KalashThakare]

What about the post run steps of an action? Eg checkout or setup node have one

Yes, they still run on cancel through the post pipeline, and they only skip if the main step never ran or the post-if condition is false.

[bircni]

What about the post run steps of an action? Eg checkout or setup node have one

Yes, they still run on cancel through the post pipeline, and they only skip if the main step never ran or the post-if condition is false.

Perfect - looking forward to review your PR

[KalashThakare]

But Looks good!!! Open a PR that's the more interesting part

Another point, what happens if one of these two don't support the cancel stuff yet? Like gitea is 1.22 but Act Runner is with your fix Or gitea is with your fix and Act Runner is not

Then things will get bit dirty, i'll have to look into this too didn't thought about it though.