internalChecksFilter: "strict" inconsistently bypassed: branches/PRs created for releases that haven't passed minimumReleaseAge

[kdeldycke]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

43.101.0

Please tell us more about your question or problem

Current behavior

Renovate 43.101.0 created branches and PRs for two GitHub Actions major updates that had not passed the minimumReleaseAge of 29 days, despite internalChecksFilter being at its default "strict" value. In the same run, other packages were correctly blocked by the filter.

Expected behavior

With the default internalChecksFilter: "strict", Renovate should not create branches for updates where minimumReleaseAge has not been met. All packages should be treated consistently within the same run.

Affected packages (bypassed the filter)

• astral-sh/setup-uv: major (v7.4.0 → v8.0.0), released 2026-03-29, ~1 day old at run time, minimumReleaseAge = 29 days
• crazy-max/ghaction-dump-context: major (v2.3.0 → v3.0.0), released 2026-03-27, ~3 days old at run time, minimumReleaseAge = 29 days

Correctly blocked package (same run, same config, same manager)

• renovatebot/github-action: minor (v46.1.4 → v46.1.7), released 2026-03-30, ~15 hours old at run time, minimumReleaseAge = 11 days

All three are GitHub Actions managed by the github-actions manager with the github-tags datasource. The blocked one was actually younger than the two that bypassed the filter.

Renovate config

Here is my renovate.json5 at the time of the runs: you can check that there is no internalChecksFilter override (relies on the default "strict"). The relevant minimumReleaseAge rules are:

minimumReleaseAge: "8 days",
packageRules: [
  {
    matchUpdateTypes: ["major"],
    minimumReleaseAge: "29 days",
  },
  {
    matchUpdateTypes: ["minor"],
    minimumReleaseAge: "11 days",
  },
  // ...
],

Workflow runs with evidence

Run 1 (info level)

This is the run that created the PRs it should have blocked: https://github.com/kdeldycke/repomatic/actions/runs/23758202043/job/69218453562

• Line 365: Branch created (branch=renovate/astral-sh-setup-uv-8.x)
• Line 367: PR created (branch=renovate/astral-sh-setup-uv-8.x)
• Line 371: Branch created (branch=renovate/crazy-max-ghaction-dump-context-3.x)
• Line 373: PR created (branch=renovate/crazy-max-ghaction-dump-context-3.x)

Resulting PRs:

• Update astral-sh/setup-uv action to v8.0.0 kdeldycke/repomatic#2472 (setup-uv v8.0.0, closed manually during investigation)
• Update crazy-max/ghaction-dump-context action to v3.0.0 kdeldycke/repomatic#2473 (ghaction-dump-context v3.0.0, merged before I noticed the issue)

Run 2 (debug level)

This run proves the filter works for other packages but not these specific ones: https://github.com/kdeldycke/repomatic/actions/runs/23760199977/job/69225374124

Correctly blocked:

• Line 7367: Branch renovate/codecov-cli-11.x creation is disabled because internalChecksFilter was not met
• Line 7387: Branch renovate/renovatebot-github-action-46.x creation is disabled because internalChecksFilter was not met

Not blocked (already created by Run 1):

• Line 7421: branchExists=true (branch=renovate/astral-sh-setup-uv-8.x)
• Line 7435: Update has not passed minimum release age (branch=renovate/astral-sh-setup-uv-8.x) with "timeElapsed": 178125404 (~2 days) vs "minimumReleaseAge": "29 days"
• Line 13313: Updating renovate/stability-days status check state to yellow (branch=renovate/astral-sh-setup-uv-8.x), so Renovate knows the age threshold isn't met, but the PR already exists

Context

This was discussed in #38324, which was marked as fixed by #38720 (Renovate 41.165.2). However that PR only fixed branch updates when pendingChecks=true. The issue here is that internalChecksFilter: "strict" failed to prevent the initial branch creation for some packages while correctly blocking others in the same run.

[dbartholomae]

We're hitting the same issue with the npm manager (not just github-actions), using the Mend.io-hosted app. We traced through the source code to understand why PR #38720's fix didn't prevent it.

Setup

// .github/renovate.json5
{
  extends: ["config:recommended"],
  schedule: ["after 6pm and before 11pm on tuesday"],
  automerge: true,
  platformAutomerge: true,
  minimumReleaseAge: "4 days",
  // internalChecksFilter not set (default "strict")
}

pnpm-workspace.yaml also has its own supply-chain gate:

minimumReleaseAge: 4320  # 3 days, in minutes

What happened

Time	Event
June 16, 06:18 UTC	knip@6.17.1 published on npm
June 16, 22:15 UTC (Tue, in-schedule)	Renovate creates PR #2460 for knip@6.16.1 on branch renovate/knip-6.x-lockfile. This version is old enough — no age violation.
June 17, 12:14 UTC (Wed)	PR #2460 manually closed. Branch is not deleted.
June 18, 08:57 UTC (Thu, out-of-schedule)	Renovate sees the existing branch, updates it to knip@6.17.1 (~2 days old, well under the 4-day minimumReleaseAge), and creates PR #2500.
June 18, 08:57 UTC	pnpm's own minimumReleaseAge rejects the package during pnpm install --no-save → artifact error → automerge blocked.

With automerge: true, if pnpm's age gate hadn't caught it, a 2-day-old package would have been merged automatically.

Why PR #38720's fix didn't prevent this

We traced the code path through the branch worker (analysis done with AI assistance — see disclaimer at the bottom).

1. Orphan branch survives because prAlreadyExisted matches by title

check-existing.ts (line ~20) looks for closed PRs matching both branch name and PR title:

let pr = await platform.findPr({
    branchName: config.branchName,
    prTitle: config.prTitle,  // "Update dependency knip to v6.17.1"
    state: '!open',
});

The closed PR #2460 has title "Update dependency knip to v6.16.1", but the new update computes title "...to v6.17.1". Titles don't match → prAlreadyExisted returns null → the early-return path that calls handleClosedPr and deletes the branch is never reached. The orphan branch survives.

2. PR #38720's guard depends on pendingChecks being set

The guard added by PR #38720 (branch/index.ts line ~307):

if (branchExists && !dependencyDashboardCheck && !prRebaseChecked) {
    if (config.pendingChecks) {
        return { branchExists: true, prNo: branchPr?.number, result: 'pending' };
    }
}

All preconditions are met in our scenario: branchExists=true, no dashboard check, branchPr is null (PR is closed) so prRebaseChecked=false. This guard should have blocked the update if config.pendingChecks was true.

But the PR was created, which means config.pendingChecks was not true — the same inconsistent propagation issue reported in this discussion.

3. The backup guard in processBranch is ineffective by default

There's a second guard (branch/index.ts line ~519) that checks stabilityStatus (computed locally from release timestamps, not propagated through the pipeline):

if (
  !dependencyDashboardCheck &&
  !branchExists &&
  config.stabilityStatus === 'yellow' &&
  ['not-pending', 'status-success'].includes(config.prCreation!)
)

This guard is ineffective for two reasons:

• It only applies when !branchExists (initial creation), but in our case the branch exists
• It only applies when prCreation is 'not-pending' or 'status-success', but the default is 'immediate'

Suggested fixes

Two independent issues, two fixes:

Fix 1: Match closed PRs by branch name only

In check-existing.ts, the prAlreadyExisted lookup should match by branch name alone (not title) when checking for closed PRs. When a new version appears for a branch that has a closed PR, the version in the title changes, and the current title-matching prevents cleanup. This creates orphan branches that bypass the initial-creation guard.

Fix 2: Make the stabilityStatus guard effective for all cases

In branch/index.ts (~line 519), remove the prCreation filter and the !branchExists condition so it acts as a reliable fallback:

if (
  !dependencyDashboardCheck &&
  config.stabilityStatus === 'yellow'
)

Unlike pendingChecks (which is propagated through lookup → flatten → generate and can be lost along the way), stabilityStatus is computed locally in processBranch from the actual release timestamps. It doesn't suffer from the same propagation reliability issues, making it a robust fallback when pendingChecks fails to be set.

Disclaimer

The source code analysis was done with Claude Code reading through the Renovate repository. We have not manually verified every line reference or stepped through a debugger. The findings should be treated as leads for investigation, not confirmed root causes.