Repository navigation
Report cached versions pending cooldown eligibility #338
Description
With a cooldown policy enabled, the proxy can contain cached artifacts for versions that are still inside the effective cooldown window. This can happen when a policy is enabled or increased after an artifact was cached. There is currently no way to list those versions or see when they become eligible.
Add a proxy cooldown pending report for distinct version PURLs with at least one cached artifact. A version is pending when its publication time is known and the current global, ecosystem, or package policy does not allow it yet.
Useful output would include:
- version PURL
- publication time
- effective cooldown
- eligibility time and remaining duration
- cached artifact count and total size
- whether direct artifact requests are currently blocked
Support JSON output so the report can feed monitoring and automation. Versions without a publication time should be reported separately as unknown and retain the cooldown library's permissive behavior.
The report depends on resolving several current gaps. Publication-time coverage and cross-registry enforcement can be separate linked issues:
- Base the report on cached artifacts. A version counts as stored only when an artifact has both
storage_pathandfetched_at; one version can have several artifacts, while a version row alone does not show that its bytes are stored. - Persist publication times consistently. The normal artifact cache write creates or updates the version row without
published_at. npm download checks and enrichment can fill it, but many cached versions have no timestamp. Registry metadata processing should save publication times where available, with a lookup or backfill path considered for existing rows. - Return the full cooldown evaluation result.
Current handlers callDone in Add cooldown package pattern overrides #407:IsAllowed, which discards the effective duration and eligibility time needed by the report.cooldownpolicy.Policy.Evaluatenow returns acooldown.Decisionwith the effective duration and eligibility time. - Apply cooldown checks consistently to cached downloads (Cooldown is not applied to artifact downloads for Cargo, RubyGems, Hex, Conda, Pub and cached Helm charts #521). npm and PyPI (Cooldown hides the version from metadata but still serves the tarball #239), NuGet, and Composer (Withhold Composer archives still in cooldown #469) check at download time. Helm filters charts in cooldown when resolving the download URL; whether a cached chart is checked needs verifying. Cargo, Conda, RubyGems, Hex and Pub only filter metadata, so their cached artifacts can be downloaded directly. Tests should enter through each public artifact endpoint with an artifact cached before the policy changes.
This is the proxy counterpart to git-pkgs/git-pkgs#353, which reports pending registry releases for dependencies in a repository. The proxy report covers artifacts already held by the proxy.
The current behavior was checked against proxy main at 8d3dacf. To reproduce the reporting gap:
- Cache an artifact through the proxy.
- Configure a cooldown that places its version inside the waiting period.
- Run
proxy statsor inspect the API and version page. - The cached version is visible, but its pending state and eligibility time are absent.
Activity
pinguinfuss commentedon Oct 18, 2026
Status
helm.go:101).Cross-cutting
published_atin UTC.PR 1 – download checks
PR 2 – persist publication times
PR 3 –
proxy cooldown pendingstorage_path,fetched_at, notlocal), grouped by version.statshas none).--json.Overlapping PRs
Open questions
--resolveoption?conda-forge/numpy), or stay name-only as today?andrew commentedon Oct 18, 2026
Thanks @pinguinfuss, the plan looks right. On the questions:
--resolvecan come later if someone asks for it.