Skip to content

Do not skip a commit because an earlier commit's marker was restored - #137

Closed
CedricConday wants to merge 1 commit into
anthropics:mainfrom
CedricConday:fix/cache-restore-keys-false-green
Closed

CedricConday wants to merge 1 commit into
anthropics:mainfrom
CedricConday:fix/cache-restore-keys-false-green

Conversation

@CedricConday

Copy link
Copy Markdown

The dedup marker is cached under a key that includes github.sha, but the restore step also carries a restore-keys prefix with no SHA in it. On a brand new commit there is no exact-key entry, so the prefix matches and the marker written by an earlier commit on the same PR is restored. The enablement check only tests that the marker file exists, so the scan is disabled for a commit that has never been analyzed and the check goes green in seconds without looking at the code.

That is also the mechanism behind #42: push a fix for a finding and the fix commit is never scanned.

The marker already records the commit it was written for. This compares it with the current SHA and discards a marker belonging to a different commit. A marker for this commit still suppresses the run, so the reservation that guards against concurrent runs on the same commit is unaffected.

Closes #120

The dedup marker is cached under a key that includes github.sha, but the
restore step also carries a restore-keys prefix with no SHA in it. On a
brand new commit there is no exact-key entry, so the prefix matches and
the marker written by an earlier commit on the same PR is restored. The
enablement check only tests that the marker file exists, so the scan is
disabled for a commit that has never been analyzed and the check goes
green in seconds without looking at the code.

That is the mechanism behind gh-42 as well: push a fix for a finding and
the fix commit is never scanned.

The marker already records the commit it was written for. Compare it with
the current SHA and discard a marker belonging to a different commit. A
marker for this commit still suppresses the run, so the reservation that
guards against concurrent runs on the same commit is unaffected.

Closes #120
@CedricConday
CedricConday deleted the fix/cache-restore-keys-false-green branch September 13, 2026 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cache restore-keys prefix-match causes scans to silently skip new commits (false green) — root cause of #42

1 participant