Clarify effect of job cancellation on following steps

[devurandom]

Code of Conduct

• I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?

https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-cancellation

What part(s) of the article would you like to see updated?

I would like to know what happens to following / future steps of a job that is being cancelled.

The documentation sadly only explicitly explains what happens to jobs that are not being cancelled (their step conditions are reevaluated to run only those that still evaluate to true), but does not mention what happens to future steps of a job if the job is was decided to be cancelled. The documentation only says that SIGINT is being sent to the GitHub Runner:

docs/content/actions/reference/workflows-and-actions/workflow-cancellation.md

Lines 18 to 22 in 0e2e86c

	1. To cancel the workflow run, the server re-evaluates `if` conditions for all currently running jobs. If the condition evaluates to `true`, the job will not get canceled. For example, the condition `if: always()` would evaluate to true and the job continues to run. When there is no condition, that is the equivalent of the condition `if: success()`, which only runs if the previous step finished successfully.
	1. For jobs that need to be canceled, the server sends a cancellation message to all the runner machines with jobs that need to be canceled.
	1. For jobs that continue to run, the server re-evaluates `if` conditions for the unfinished steps. If the condition evaluates to `true`, the step continues to run. You can use the `cancelled` expression to apply a status check of `cancelled()`. For more information, see [AUTOTITLE](/actions/reference/workflows-and-actions/expressions#cancelled).
	1. For steps that need to be canceled, the runner machine sends `SIGINT/Ctrl-C` to the step's entry process (`node` for JavaScript actions, `docker` for container actions, and `bash/cmd/pwd` when using `run` in a step). If the process doesn't exit within 7500 ms, the runner will send `SIGTERM/Ctrl-Break` to the process, then wait for 2500 ms for the process to exit. If the process is still running, the runner kills the process tree.
	1. After the 5 minute cancellation timeout period, the server will forcibly terminate all jobs and steps marked for cancellation that are still running.

A community discussion quotes the GitHub engineering team with:

7. [if the condition of the currently running step evaluates to false], the runner will send Ctrl-C to the action entry process (node for javascript action, docker for container action, and bash/cmd/pwd for run action), if the process doesn’t exit within 7500ms, the runner will send Ctrl-Break to the process, then wait for 2500ms for the process to exit. the runner will terminate the process tree if the process is still running.
8. The runner will try all the following steps that have condition sets to always() as many as it can within the 5 minutes cancellation timeout.

(https://github.com/orgs/community/discussions/26311#discussioncomment-3251359)

The last bit provides the explanation I am looking for, but it is not clear whether it correctly reflects how GitHub Actions is officially designed to behave, and since it is 6 years old it is not clear whether it is still correct.

Additional information

No response