renovate/stability-days permanently pending for digest and lockFileMaintenance: branch-level check ignores the lookup-stage timestamp handling

[esetnik]

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.}

[RahulGautamSingh]

Issue Created: #45236

Thanks for the detailed writeup. The solution you proposed sounds good as well, PR welcome.