Content cache is cleared when a repository version is started, so concurrent requests re-cache the previous version
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
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:
- Create a Python repository and a distribution for it, with the cache enabled.
- Keep a few clients polling
GET /pypi/<base_path>/simple/<name>/, every half second or so. - Upload a new package, or a new version of an existing one, into the repository and wait for the task.
- 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__, throughtransaction.on_commit. A version that changes nothing is discarded, and would then no longer clear the cache at all. - Publications already invalidate after
complete=Trueis 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
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di pulp/pulpcore
-
Reclaim Space Server ErrorApertaIssue
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Feature
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
pulp/pulpcore#5802 · 10 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Issue Triage-Needed
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
I maintainer di solito rispondono entro 1 giorno
-
Issue Triage-Needed
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
-
Content app answers 404 instead of 502 when the remote of on-demand content is unavailableForse già presa @gigi206 l’ha presa 13 giorni fa. ApertaTriage-Needed
Difficoltà 3/5 Mezza giornata Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di pulp/pulpcore
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
nansencenter/geodataset#39 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
awslabs/visual-asset-management-system#804 ·
I maintainer di solito rispondono entro 1 giorno
-
follow-up
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
odoo/odoo#297927 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
link-rot
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 67/100