Don't record an overlay status when the job was cancelled

[henrymercer]

The overlay status mechanism records a marker in the Actions cache when building an overlay-base database fails, so that later runs skip overlay analysis instead of failing the same way, but it records one whenever the analyze step did not report success, which also covers runs that were cancelled, since the init post step still runs in that case. A cancellation tells us nothing about whether the analysis would have succeeded, and a marker disables overlay analysis for the whole repository until the next CodeQL release, so this adds an internal job-status input defaulting to ${{ job.status }} and skips recording when the job was cancelled.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Workflow types:

• Advanced setup - Impacts users who have custom CodeQL workflows.
• Managed - Impacts users with dynamic workflows (Default Setup, Code Quality, ...).

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.

How did/will you validate this change?

• Test repository - This change will be tested on a test repository before merging, specifically to confirm that a cancelled run reports cancelled to the post step.
• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Feature flags - The behaviour change only takes effect where overlay_analysis_status_save is enabled, so disabling that flag restores the previous behaviour. The new input is inert on its own.

How will you know if something goes wrong after this change is released?

• Telemetry - I rely on existing telemetry. The codeql-action/overlay-disabled diagnostic reports skipped-due-to-cached-status, so the rate of that reason shows whether we are recording fewer markers as intended, and overlay adoption shows whether we have stopped recording ones we needed.

Are there any special considerations for merging or releasing this change?

• No special considerations - This change can be merged at any time.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change. Not added, since the behaviour is gated behind an existing feature flag, matching earlier changes to this mechanism.
• Confirm the readme and docs have been updated if necessary.

[Copilot]

Warning

• Copilot's review of this pull request may be incomplete because some of the changed files are excluded by your Copilot content exclusion settings. See Excluding content from Copilot for details.

Copilot review overview

🟢 Approval recommended

The focused implementation is consistent with existing input handling and covers the new behavior with unit tests.

Review tier: Balanced
Findings: None

What changed in this PR

Prevents cancelled jobs from incorrectly disabling overlay analysis through cached failure markers.

Changes:

• Passes the runtime job status into post-processing.
• Skips overlay failure recording for cancellations unless CodeQL already reported an error.
• Adds unit coverage for cancellation scenarios.

File	Description
src/​init-action-post.ts	Captures post-step job status before restoring inputs.
src/​init-action-post-helper.ts	Adds cancellation-aware overlay status handling.
src/​init-action-post-helper.test.ts	Tests cancellation and prior-error behavior.
init/​action.yml	Defines the internal job-status input.
lib/​entry-points.js	Generated output; excluded from review by policy.

Files excluded by content exclusion policy (1)

• lib/entry-points.js

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[oscarsj]

good catch