Timeout without approval triggered dependent jobs

[rgrzesk]

• 🆗 I have searched through the current issues and did not find any that were related.

The manual-approval action failed to block dependent jobs after the 6-hour timeout expired. Specifically, on June 27, 2025, the approval step timed out (as expected), but jobs that depended on it were still executed — even though no manual approval had been provided.

Interestingly, on June 30, 2025, we triggered another workflow run using the exact same configuration, and this time the behavior was correct: the approval step timed out and downstream jobs were not executed. This indicates non-deterministic behavior, possibly due to a race condition or inconsistent job state propagation within GitHub Actions.

To Reproduce:

1. Use trstringer/manual-approval@v1 in a workflow with minimum-approvals: 1.
2. Add downstream jobs that depend on the manual-approval job using needs: [approve].
3. In the downstream jobs, use a conditional like if: ${{ always() && !failure() && !cancelled() }}.
4. Trigger the workflow but do not approve it.
5. Wait for the 6-hour timeout to expire.
6. Observe whether the downstream jobs run or not — in our case, they did run on 27.06, but did not run on 30.06, despite no changes to the workflow.

Expected behavior

1. When the approval step times out:

• The approve job should fail.
• All jobs that depend on it should not run, unless explicitly configured to bypass approval logic.

jobs:
  approve:
    runs-on: ubuntu-latest
    steps:
      - uses: trstringer/manual-approval@v1
        with:
          secret: ${{ github.TOKEN }}
          approvers: someone
          minimum-approvals: 1

  follow-up-job:
    needs: approve
    runs-on: ubuntu-latest
    if: ${{ always() && !failure() && !cancelled() }}
    steps:
      - run: echo "Running follow-up task"

Additional context

• The issue appears to be intermittent. Our June 27 run demonstrated the failure scenario; our June 30 run behaved correctly.
• The job was not approved in either case.
• We suspect either a timing/race condition or an inconsistency in how GitHub Actions handles needs: relationships when a job times out due to manual-approval.

[lizziemac]

Hi @rgrzesk — thanks for using manual-approval. Since this relates to how GitHub Actions handles timeouts, it's not likely an issue with manual-approval itself, but I have some thoughts and suggestions:

• are you using the approval-status flag from manual-approval? I would recommend using this instead of failure and cancelled. If it's empty, you can consider that a timeout/failure as well, although with the following suggestion i don't believe it will even be checked.
• explicitly add the timeout-minutes parameter to the manual-approval step. See guidance here. This is a GitHub Actions parameter, not a manual approval one, but I'm thinking being more explicit may guarantee the timeout behavior you want.
• && !cancelled() will always be true, from my own testing, for two reasons:
  • If a job is canceled by GitHub Actions, all its steps are cancelled, so any conditional depending on cancelled() is never evaluated.
  • even if that weren’t true, the manual-approval action doesn’t expose any way to detect that it was individually canceled, so the check wouldn't help here.