minimumReleaseAge: branch-stage stability check leaves digest and lockFileMaintenance PRs permanently pending

[RahulGautamSingh]

Discussed in #45202

^{Originally posted by esetnik August 10, 2026}

What is happening

With a top-level minimumReleaseAge: "1 day", every Docker digest PR and every lockFileMaintenance PR in our repo opens with renovate/stability-days set to pending / "Updates have not met minimum release age requirement", and that check never turns green.

Concrete case: a PR bumping golang:1.26.5-bookworm from digest 1ecb7ed to 6c5605a.

• Docker Hub reports tag_last_pushed: 2026-08-05T10:23:11Z for that tag, and the tag currently resolves to sha256:6c5605ab…, the digest in the PR.
• The PR was opened 2026-08-10T10:21Z; the pending status was posted 2026-08-10T10:48Z and was still pending at 2026-08-10T15:00Z.

A five day old image cannot fail a one day minimumReleaseAge, so this is not a timer waiting to elapse. The check is reporting "has not met minimum release age" for an update whose age is simply unknown to it.

What I believe the cause is (44.12.0)

minimumReleaseAge is evaluated in two places, and only the first one knows about the update types that have no releaseTimestamp wired in:

1. Lookup stage. isMinimumReleaseAgeApplicable() in lib/workers/repository/process/lookup/filter-checks.ts excludes lockFileMaintenance (along with pin and replacement, per Package pinning (updateType=pin) does not have a release timestamp wired in #40288 and Replacements do not have a release timestamp wired in  #39400), and applyMinimumReleaseAgeToDigestUpdate() in lib/workers/repository/process/lookup/index.ts ages a digest update against newestMatchingVersionTimestamp, the timestamp of the newest version matching the current value. Both of my update types pass here, which is why the branch and PR get created at all.

2. Branch stage. The stability block in lib/workers/repository/update/branch/index.ts iterates config.upgrades and reads upgrade.releaseTimestamp directly. For a digest update that field is not populated (as documented in docs(docker): note digests may have an incorrect releaseTimestamp #38658), and a lockFileMaintenance upgrade has no release to speak of. Since minimumReleaseAgeBehaviour defaults to timestamp-required (feat(minimumReleaseAge)!: require a release timestamp by default #38843), both fall into the "no timestamp, therefore pending" path and config.stabilityStatus is set to yellow on every run, indefinitely.

So the branch-level status check contradicts the decision the lookup stage already made: lookup concludes "aged, proceed", the status check reports "has not met minimum release age".

Why it matters

• A permanently unresolvable yellow check on every digest and lock-file-maintenance PR, which teaches reviewers to ignore the check entirely.
• automerge cannot complete on those branches, because internalChecksAsSuccess defaults to false. That failure is silent.
• The symptom is invisible under prCreation: not-pending or status-success, where the same yellow status suppresses branch creation. There the PR is simply never opened, which is arguably worse.

Suggestion

Teach the branch stage what the lookup stage already knows: skip the stability status for upgrades whose updateType fails isMinimumReleaseAgeApplicable(), and for digest / pinDigest reuse the same newestMatchingVersionTimestamp that applyMinimumReleaseAgeToDigestUpdate() used rather than dropping into the missing-timestamp path. That would also keep the existing "keep in sync" note in filter-checks.ts honest.

Related open work on the underlying timestamp gap: #38656, #38659, #37196.

Workaround

{
  "matchUpdateTypes": ["digest", "pinDigest", "lockFileMaintenance"],
  "minimumReleaseAgeBehaviour": "timestamp-optional"
}

Environment

Mend-hosted Renovate, GitHub. renovate-debug blob on the PR reports createdInVer and updatedInVer of 44.12.0; all source references above are to the 44.12.0 tag. I can only reach job logs through the Mend developer portal, so tell me what you need from them and I will pull it.

_{Analysis drafted with AI assistance (Claude Code). The timestamps, status-check history and source references above were each verified directly against the Docker Hub API, the GitHub statuses API and the 44.12.0 source.}

[Boulea7]

I am working on this. I reproduced both branch-stage mismatches on current main with focused failing regression tests: lockFileMaintenance is held under timestamp-required even though minimum release age does not apply to it, and an aged digest lookup drops the newest matching version timestamp before branch processing. I plan to keep the fix scoped to the existing applicability rule and digest timestamp propagation, with regression coverage for both paths.

[Boulea7]

After checking the surrounding work more closely, I found that open PR #44921 is refactoring the same branch stability block. I also confirmed that carrying the digest age input forward needs a dedicated timestamp meaning rather than reusing releaseTimestamp, which represents the new release timestamp elsewhere. To avoid conflicting or duplicative work, I am stepping back from this for now.

[knu]

github-runner updates (e.g. runs-on: ubuntu-22.04 → 24.04) hit the same trap: the github-runners datasource is a hardcoded list with no releaseTimestamp at all, so with the default timestamp-required every release is marked pending at the lookup stage and renovate/stability-days stays yellow forever — even though Ubuntu 24.04 has been GA for over two years.

Workaround: { matchDepTypes: ["github-runner"], minimumReleaseAge: null }. It would be good if the fix also covers datasources that structurally never provide timestamps.