404 Not Found for manifest after upstream update in Harbor proxy cache
0 reputation · 04 Mar 2022, 14:19 UTC
Problem Context
When an upstream registry updates a mutable tag, Harbor’s proxy cache may still serve a previously cached manifest. The Docker client then receives a 404 Not Found when pulling the new digest, indicating that the proxy cache has not yet been refreshed.
Constraints & Uncertainty
Proxy cache entries are governed by a configurable TTL, and Harbor does not currently perform synchronous invalidation on upstream writes. The core UI and API rely on Redis for metadata caching, which also respects TTLs. This design leaves a trade‑off between consistency (immediate invalidation) and performance (batch TTL expiration).
Key Questions
1. Does Harbor provide any mechanism to trigger immediate cache invalidation for a specific manifest or tag when the upstream content changes?
2. If not, how does the current TTL setting impact the window during which stale manifests may be served, and can this window be reduced without degrading overall cache hit rates?
3. Are there version‑specific differences (e.g., Harbor 2.x vs 3.x) that alter the invalidation behavior for proxy and metadata caches?
harbor