minimumReleaseAge silently suppresses all updates for large Docker Hub images (tags pagination 403 drops every releaseTimestamp)

[pdecat]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

44.69.11

Please tell us more about your question or problem

With minimumReleaseAge: "7 days" and internalChecksFilter: "strict", a Docker Hub image we pin was never proposed for update. No PR, no branch, no pending status check, nothing at INFO. The dependency extracts fine and a much newer version exists, so it looked like our config was wrong.

The cause is that every release arrives without a releaseTimestamp, and with minimumReleaseAgeBehaviour at its default timestamp-required that makes all of them pending. internalChecksFilter: "strict" then drops pending updates entirely, so there is no branch and no pending check to hint that anything happened.

Minimal reproduction

Two files in an empty directory, no token and no platform setup, using --platform=local:

Dockerfile

FROM renovate/renovate:44.69.11

renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "minimumReleaseAge": "7 days"
}

internalChecksFilter already defaults to strict and dockerMaxPages to 20, so nothing else needs setting.

$ LOG_LEVEL=debug RENOVATE_PLATFORM=local npx renovate@44.69.11 --dry-run=lookup

Then the same run with the pagination capped one page lower:

$ LOG_LEVEL=debug RENOVATE_PLATFORM=local RENOVATE_DOCKER_MAX_PAGES=10 npx renovate@44.69.11 --dry-run=lookup

Observed difference, measured 2026-09-17:

	dockerMaxPages 20 (default)	dockerMaxPages 10
Docker Hub 403s	1	0
releases marked pending	69	0
version selected	none usable	44.75.1

The counts drift as new versions are published, so a later run shows different numbers, but the pattern holds.

Both files are also in a public repository, following the minimal-reproduction instructions: https://github.com/pdecat/renovate-repro-46272

Any Docker Hub image with more than ~1000 tags should do; renovate/renovate is just a convenient one.

Why the timestamps go missing

renovate/renovate has thousands of tags, so the tag fetch paginates, and anonymously hub.docker.com caps at 1000 results. That cap is hard and reproducible, not a rate limit that comes and goes:

page 1   200
page 5   200
page 9   200
page 10  200
page 11  403
page 12  403
page 15  403

_getDockerHubTags then does this:

if (err) {
  logger.debug({ err }, `Docker: error fetching data from DockerHub`);
  return null;
}

So the ten pages it already fetched are thrown away, not just the failed one. Lookup falls back to the registry v2 tag list, which has no timestamps at all.

Only images with more than ~1000 tags paginate deep enough to reach this. Smaller ones finish in a page or two and are unaffected, which is why this looked like a problem with one specific pin.

Workaround

dockerMaxPages: 10 stops one page short of the wall, so the loop never enters the error branch and the newest 1000 tags keep their timestamps. ordering=last_updated means those are the ones that matter anyway.

Worth noting what the selected version is once that is in place: the newest release older than 7 days, not the same-day latest. So the age gate behaves exactly as intended as soon as timestamps are present. That corrected a wrong assumption on our side too, that minimumReleaseAge pends forever on a package releasing ~10 times a day. It does not, it picks the newest eligible version quite happily once it can see the dates.

Authenticating the host does not seem possible

The obvious fix looked like a host rule for hub.docker.com, since our existing one is matchHost: "docker.io" and matchHost is exact. But that API wants a session JWT from POST /v2/users/login, while lib/util/http/auth.ts only ever emits Basic or Bearer. Tried against a real Docker Hub PAT on the page that 403s:

• Basic <user:pat> -> 403
• Bearer <pat> -> 401
• JWT <pat> -> 403
• JWT <session token from /v2/users/login> -> 200

So a host rule there is inert, and adding one looks like a fix while changing nothing. Happy to be told there is a supported way to do it that I missed.

Questions

1. Is discarding the already-fetched pages on error intended? Keeping them (a break rather than return null, falling through to the existing cache.save() / cache.getItems() path, which is what hitting dockerMaxPages already does) would turn a partial fetch into partial data instead of no data. That looks like the same shape as fix(datasource/go): don't cache null on non-404/410 goproxy errors #45638 for the go datasource, where caching null on a non-404/410 error was treated as a bug.
2. Would it be worth defaulting dockerMaxPages to 10 for hub.docker.com specifically, given the anonymous cap sits exactly there? At the current default of 20 an unauthenticated install reaches it every time on a large image.
3. Separately, the silence is the part that cost the most time. A pending update that is filtered out by internalChecksFilter: "strict" leaves no trace above debug. Is there an existing way to surface "N updates were suppressed because their releases have no timestamp"? The dependency dashboard did not show it either.

Happy to open an issue or a PR for whichever of these is wanted.

Logs (if relevant)

Logs

DEBUG: GET https://hub.docker.com/v2/repositories/renovate/renovate/tags?ordering=last_updated&page=11&page_size=100
       = (code=ERR_NON_2XX_3XX_RESPONSE, statusCode=403 retryCount=0, duration=102)
DEBUG: Docker: error fetching data from DockerHub
DEBUG: Marking 64 release(s) as pending, as they do not have a releaseTimestamp and we're running with minimumReleaseAgeBehaviour=timestamp-required (repository=local)

[RahulGautamSingh]

The cause is in _getDockerHubTags(): when any page fails, it returns null and drops the pages it already fetched. Renovate then falls back to the plain registry tag list, which has no timestamps, so every release looks pending under minimumReleaseAge.

On self-hosted Renovate, set dockerMaxPages to stop before the page that fails:

 {
   "dockerMaxPages": 10
 }

Docker Hub returns tags ordered by last_updated, so the first 10 pages hold the newest tags, which are the ones minimumReleaseAge needs.

PS: dockerMaxPages is a global option, so the Mend-hosted app cannot set it. Needs a fix PR, which keeps the pages already fetched when a later page fails.

[RahulGautamSingh]

Issue Created: #46925