Disable missing diff-ranges fallback when overlay enabled manually#3939
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR refines how overlay analysis behaves when diff ranges are unavailable by introducing an explicit “overlay mode was manually set” signal, so that the existing “missing diff-ranges → fall back to non-overlay” behavior is skipped when overlay is forced via CODEQL_OVERLAY_DATABASE_MODE.
Changes:
- Add
overlayModeSetExplicitlyto the actionConfigand propagate it from overlay enablement into the final config. - Disable the “missing diff ranges” overlay fallback when overlay was explicitly selected.
- Extend unit tests to assert the new behavior and to validate the explicit-vs-automatic distinction.
Show a summary per file
| File | Description |
|---|---|
| src/testing-utils.ts | Extend createTestConfig defaults to include overlayModeSetExplicitly. |
| src/config-utils.ts | Add overlayModeSetExplicitly to Config, thread it through overlay enablement, and gate the diff-ranges fallback on it. |
| src/config-utils.test.ts | Update overlay enablement expectations and add coverage for the new explicit-overlay/no-diff behavior. |
| lib/entry-points.js | Generated output reflecting the TypeScript changes (not reviewed). |
Copilot's findings
- Files reviewed: 3/4 changed files
- Comments generated: 4
Comment on lines
+246
to
+249
| /** | ||
| * Whether the overlay database mode was set explicitly. | ||
| */ | ||
| overlayModeSetExplicitly: boolean; |
Comment on lines
+1099
to
+1101
| * Query exclusions for incremental-only queries are then applied whenever the diff ranges are | ||
| * available — which, after the fallback above, is exactly the set of runs where any kind of | ||
| * incremental analysis (overlay or diff-informed) is in effect. |
Comment on lines
+246
to
+249
| /** | ||
| * Whether the overlay database mode was set explicitly. | ||
| */ | ||
| overlayModeSetExplicitly: boolean; |
Comment on lines
+1099
to
+1101
| * Query exclusions for incremental-only queries are then applied whenever the diff ranges are | ||
| * available — which, after the fallback above, is exactly the set of runs where any kind of | ||
| * incremental analysis (overlay or diff-informed) is in effect. |
mario-campos
approved these changes
Jun 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If overlay is enabled explicitly via the
CODEQL_OVERLAY_DATABASE_MODEenvironment variable, then disable the diff-ranges fallback. This means that when the environment variable is set, overlay will be enabled even if diff-ranges are missing.Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
dynamicworkflows (Default Setup, Code Quality, ...).Products:
analysis-kinds: code-scanning.Environments:
github.comand/or GitHub Enterprise Cloud with Data Residency.How did/will you validate this change?
.test.tsfiles).If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist