[BUG] Stop tag enumeration on Docker Hub 429 causes multi-year back-off in v0.9.x

[gitfeber]

Describe the bug When running version-checker v0.9.0 or v0.9.1 against Docker Hub without authentication, tag enumeration stops as soon as a 429 Too Many Requests is returned. The process enters an extremely long back-off (e.g. “retrying in 485009h…”), so you only see a small subset of your images in Prometheus. This did not happen in v0.8.6, where all tags were fetched successfully.

To Reproduce

1. Deploy version-checker v0.9.1 with only these args (no --docker-token for Docker Hub):

containers:
- name: version-checker
  image: quay.io/jetstack/version-checker:v0.9.1
  args:
    - "--test-all-containers"
    - "--metrics-serving-address=0.0.0.0:8181"

2. Wait for the first scrape cycle to finish.

3. Inspect the logs and you’ll see entries like:

time="2025-04-30T17:58:52Z" level=info msg="[DEBUG] GET https://registry.hub.docker.com/v2/repositories/bitnami/oauth2-proxy/tags?page=19&page_size=100 (status: 429): retrying in 485009h59m52s (10 left)" client=docker component=client

4. Check Prometheus: only the first pages were fetched; all remaining repositories are missing.

Expected behavior Version-checker should either retry after a short delay (e.g. a few seconds) and continue enumeration, or upon the first 429, skip only that single request and proceed with the next repository, instead of entering a multi-year back-off.

Screenshots time="2025-04-30T17:58:52Z" level=info msg="[DEBUG] GET https://registry.hub.docker.com/v2/repositories/bitnami/oauth2-proxy/tags?page=19&page_size=100 (status: 429): retrying in 485009h59m52s (10 left)" client=docker component=client

Environment (please complete the following information):

• Version-Checker: v0.9.0 & v0.9.1
• Kubernetes: v1.31.8
• Prometheus: v3.3.0
• Grafana: v9.5.0 Container Registry: registry.hub.docker.com (anonymous pull and docker token pull)

Additional context

• In v0.8.6, the complete tag listing worked without any rate-limit interruptions.
• Docker Hub enforces an “abuse limit” on unauthenticated API requests, which currently halts the scan completely when hit.
• A more graceful retry strategy or skipping on 429 would restore full coverage.

[davidcollom]

Hi, thanks for raising this issue, I had noticed this during testing and had repaired #354 in response - This has been merged and I'll work to get a 0.9.2 release out today! 👍

[davidcollom]

@gitfeber - 0.9.2 should now be released, If you could please test and report back if this is resolved so we can keep issues clear it would be great! 👍

[gitfeber]

@davidcollom The back-off looks good now, but a new problem appeared:

Some images are displayed multiple times instead of replacing each other with the latest version thats available. I saw that v.0.9.3 got published, i will deploy this and test it with this one 👍

[davidcollom]

That would be great, @gitfeber, if you can. As with the other issue mentioned, it would be appreciated if this could be logged as a separate issue so that we can better investigate. However, one thing to check is if you're using an instant query and if this was simply a timing of metrics still being tracked from the previous instance of version-checker.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity in the last 90 days. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity in the last 90 days. It will be closed if no further activity occurs. Thank you for your contributions.