Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Content cache is cleared when a repository version is started, so concurrent requests re-cache the previous version

Chiusa
#8,246 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #8247 di @aevnsvi — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python, redis
Ambito
backend, databases

Direzione di ricerca

Start with Repository.new_version() and RepositoryVersion.__exit__ in pulpcore, then check the cache invalidation tests and how distributions serve repository content. Trace when a version is committed and when the response cache is cleared; done means concurrent requests cannot leave the previous version cached after the version task completes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Version
pulpcore main (0f6df7d), with the content cache enabled (CACHE_ENABLED = True, Redis).

Describe the bug
Repository.new_version() clears the response cache of the distributions serving the repository when the new version is started. The version only becomes complete later, in RepositoryVersion.__exit__. In between, those distributions are still served from the previous version. A request that arrives in that window puts the previous answer back into the freshly cleared cache. It is then served until the entry expires (CACHE_SETTINGS["EXPIRES_TTL"], 600 seconds by default), although the new version exists by then. Nothing clears the cache again when the version completes.

Without concurrent requests the invalidation works, which makes this easy to miss in a test. Under real traffic, an upload is invisible for up to the full TTL.

To Reproduce
It shows most clearly where an index is served through the cache, for example the pulp_python simple API:

  1. Create a Python repository and a distribution for it, with the cache enabled.
  2. Keep a few clients polling GET /pypi/<base_path>/simple/<name>/, every half second or so.
  3. Upload a new package, or a new version of an existing one, into the repository and wait for the task.
  4. The polling clients keep getting the index without the new file for about ten minutes.

I ran this three times each for a new name and a new version, with four clients polling. The old index stayed cached in every run, and also with a single client. With the cache disabled nothing is stale, so the race is in the invalidation, not in the version itself.

Expected behavior
After the task that creates a repository version has finished, the distributions serving that repository answer from the new version.

Additional context

  • The cache can be cleared once the version is complete and committed instead: in RepositoryVersion.__exit__, through transaction.on_commit. A version that changes nothing is discarded, and would then no longer clear the cache at all.
  • Publications already invalidate after complete=True is saved, so they are not affected.
  • Deleting a version needs no change: a version that a distribution serves is protected from deletion.
  • #2026 is about Redis outages, a different case.

I have a patch with unit tests, and can open it as a PR.

Lingua principale
Python
Stelle
612
Fork
175
Merge medio
15h 47m
PR unite (30g)
117

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pulp/pulpcore

Tutte le issue di pulp/pulpcore

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.