bug: pipedv1 deployment store returns newest deployment as head, not oldest
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
- #6921 di @AruneshDwivedi — chiusa senza merge
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- go
- Ambito
- devops, infrastructure
Direzione di ricerca
Inizia da ListAppHeadDeployments in pkg/app/pipedv1/apistore/deploymentstore/store.go:125-134 e dall’implementazione corrispondente in pkg/app/piped/apistore/deploymentstore/store.go. Traccia dove viene usato il metodo per determinare se l’head debba essere il deployment non completato più vecchio o più recente, quindi aggiungi per entrambi gli store il test di regressione con due deployment descritto nell’issue. Il lavoro è completato quando l’implementazione e il docstring di Lister concordano.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What happened:
While reviewing the deployment store sync logic in pipedv1, the head-deployment selection in pkg/app/pipedv1/apistore/deploymentstore/store.go:125-134 looks inverted relative to the Lister interface's docstring.
The interface promises:
ListAppHeadDeploymentsreturns the map from application ID to its head of deploying deployments.
Head deployment is same with the oldest uncompleted one.
But the implementation writes pendings → planneds → runnings into the same map[string]*model.Deployment, so for an application with both a pending and a running deployment, the running one wins by overwrite order:
for _, d := range pendings { headDeployments[d.ApplicationId] = d }
for _, d := range planneds { headDeployments[d.ApplicationId] = d }
for _, d := range runnings { headDeployments[d.ApplicationId] = d }
A PENDING deployment is logically newer than a RUNNING one for the same application (it was created later, after the running one started), so this code returns the newest uncompleted deployment, not the oldest.
The same inversion exists at the corresponding location in the v0 store (pkg/app/piped/apistore/deploymentstore/store.go).
What you expected to happen:
Either:
- The docstring is updated to match the implementation ("head = newest uncompleted"), or
- The implementation is corrected to match the docstring — either reverse the write order or pick the head explicitly by
created_at.
I don't know which side is correct, since I haven't traced where ListAppHeadDeployments is consumed downstream. Whichever way it ends up, the docstring and the code should agree.
How to reproduce it:
Unit test against the store with two *model.Deployment instances sharing one ApplicationId, one DEPLOYMENT_PENDING and one DEPLOYMENT_RUNNING. Lister.ListAppHeadDeployments()[appID] returns the running one — the opposite of what the docstring promises.
Environment:
pipedversion: master @78fdbeb7c(both v0 and v1 affected)control-planeversion: same- Others: surfaced during self-review of #6727 while writing tests for
ListAppHeadDeployments
- Lingua principale
- Go
- Stelle
- 1.4k
- Fork
- 391
- Merge medio
- 4g 1h
- PR unite (30g)
- 58
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 pipe-cd/pipecd
-
Applications at the repository root are not triggered by new commitsForse già presa @Daksha1611 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 2 giorni
-
pipedv1 kubernetes plugins ignore trafficRouting.istio.host in K8S_TRAFFIC_ROUTINGForse già presa @Dhirenderchoudhary l’ha presa oggi. Aperta
Difficoltà 2/5 Mezza giornata Idoneità per principianti 74/100
pipe-cd/pipecd#7626 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 2 giorni
-
pipectl transfer restore application drops backed-up labelsForse già presa @bhavishyajain545 l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
pipe-cd/pipecd#7622 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di pipe-cd/pipecd
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
docker-compose: postgres healthcheck should probe TCP (pg_isready -h localhost)Forse già presa @zezo-mohamed22 l’ha presa oggi. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
OneBusAway/watchdog#305 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
self-care self-care:agent-discoverability
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
githubnext/gh-cao#20928 ·
I maintainer di solito rispondono entro 1 giorno
-
automation documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
SocialGouv/iterion#3287 ·
I maintainer di solito rispondono entro 1 giorno