fix(master): clear a stale available suggestion after a tag switch #33

Open
opened 2026-10-13 11:44:40 +00:00 by shcizo · 0 comments
Owner

Beskrivning

När en tjänst byter tag ligger det gamla "Update available" kvar för alltid. Exempel: en tjänst kör gitea/gitea:1.27.3 och pollern har registrerat en ny digest under 1.27.3 (available_ref = gitea/gitea:1.27.3). Du deployar sedan 1.28.0, t.ex. via förslaget "Newer tag" från #11 eller via versionslistan. Tjänsten kör nu 1.28.0, men chippet "Update available 1.27.3" står kvar i översikten, och auto-tjänster visar ett förslag som pekar bakåt.

Felet fanns före #11 (en version pick till en annan tag ger samma resultat), men med #11 blir tagbyten vanliga.

Förväntat beteende

Ett förslag från pollern gäller den tag tjänsten följer. När tjänsten följer en annan tag ska available_* tömmas.

Steg för att reproducera

  1. En tjänst kör repo:1.0.0, och registryt får en ny digest under 1.0.0. Efter en poll-cycle visas "Update available 1.0.0".
  2. Deploya repo:1.1.0 från versionslistan, eller med "Newer tag".
  3. Efter jobbet och nästa poll-cycle visas fortfarande "Update available 1.0.0".

Teknisk orsak

  • FinishJob (internal/master/store/jobs.go) tömmer available_* bara när jobbets to_ref, utan @digest, är exakt lika med available_ref. Ett jobb till repo:1.1.0 matchar aldrig repo:1.0.0.
  • Pollern (internal/master/poller/poller.go, suggest) grupperar tjänsten under den nya taggen repo:1.1.0. Eftersom ActualDigest == l.digest returnerar den tidigt utan att skriva något, och det gamla available_ref rörs aldrig.
  • Ingen annan kod tömmer available_*.

Förslag till lösning

Låt pollern tömma ett poll-förslag (available_source = 'poll') när available_ref inte är den ref tjänsten följer nu (jobs.FollowedRef(actual_ref)). Pollern skrev förslaget, så det är pollern som ska tömma det. Det fungerar oavsett hur tagbytet skedde: jobb, manuell docker compose up eller ändrad stackfil. FinishJob och reglerna för när den tömmer available_* lämnas orörda.

  • Ny store-metod ClearAvailable(id), eller SetAvailable med ett tomt värde. Den skriver bara vid ändring och publicerar events.Services.
  • Gäller inte borttagna tjänster, tjänster som hoppas över av SkipReason, eller tjänster som följer en tag vars uppslag misslyckades i den här cycle.
  • Test i poller_test.go och ett integrationstest i store.

Öppen fråga

Webhook-förslag (available_source = 'webhook') kan med avsikt peka på en annan tag än den tjänsten följer. CI kan till exempel säga "1.28.0 finns" om en manuell tjänst som kör 1.27.3. Då är förslaget inte inaktuellt utan själva poängen. Förslag: rör inte webhook-förslag i den här issuen. De töms redan av FinishJob när just den versionen deployas. Behöver de en egen regel, t.ex. "töm om tjänsten redan kör en tag som är lika med eller nyare än förslaget enligt tagver", blir det en separat issue.

Scope

  • Ingår: att pollern tömmer inaktuella poll-förslag, plus tester.
  • Ingår inte: webhook-förslag, ändringar i FinishJob, newer_* (#11 hanterar det redan i pollern och när sidan visas).
## Beskrivning När en tjänst byter tag ligger det gamla "Update available" kvar för alltid. Exempel: en tjänst kör `gitea/gitea:1.27.3` och pollern har registrerat en ny digest under `1.27.3` (`available_ref = gitea/gitea:1.27.3`). Du deployar sedan `1.28.0`, t.ex. via förslaget "Newer tag" från #11 eller via versionslistan. Tjänsten kör nu `1.28.0`, men chippet "Update available 1.27.3" står kvar i översikten, och auto-tjänster visar ett förslag som pekar bakåt. Felet fanns före #11 (en version pick till en annan tag ger samma resultat), men med #11 blir tagbyten vanliga. ## Förväntat beteende Ett förslag från pollern gäller den tag tjänsten följer. När tjänsten följer en annan tag ska `available_*` tömmas. ## Steg för att reproducera 1. En tjänst kör `repo:1.0.0`, och registryt får en ny digest under `1.0.0`. Efter en poll-cycle visas "Update available 1.0.0". 2. Deploya `repo:1.1.0` från versionslistan, eller med "Newer tag". 3. Efter jobbet och nästa poll-cycle visas fortfarande "Update available 1.0.0". ## Teknisk orsak - `FinishJob` (`internal/master/store/jobs.go`) tömmer `available_*` bara när jobbets `to_ref`, utan `@digest`, är exakt lika med `available_ref`. Ett jobb till `repo:1.1.0` matchar aldrig `repo:1.0.0`. - Pollern (`internal/master/poller/poller.go`, `suggest`) grupperar tjänsten under den nya taggen `repo:1.1.0`. Eftersom `ActualDigest == l.digest` returnerar den tidigt utan att skriva något, och det gamla `available_ref` rörs aldrig. - Ingen annan kod tömmer `available_*`. ## Förslag till lösning Låt pollern tömma ett **poll**-förslag (`available_source = 'poll'`) när `available_ref` inte är den ref tjänsten följer nu (`jobs.FollowedRef(actual_ref)`). Pollern skrev förslaget, så det är pollern som ska tömma det. Det fungerar oavsett hur tagbytet skedde: jobb, manuell `docker compose up` eller ändrad stackfil. `FinishJob` och reglerna för när den tömmer `available_*` lämnas orörda. - Ny store-metod `ClearAvailable(id)`, eller `SetAvailable` med ett tomt värde. Den skriver bara vid ändring och publicerar `events.Services`. - Gäller inte borttagna tjänster, tjänster som hoppas över av `SkipReason`, eller tjänster som följer en tag vars uppslag misslyckades i den här cycle. - Test i `poller_test.go` och ett integrationstest i store. ## Öppen fråga **Webhook-förslag** (`available_source = 'webhook'`) kan med avsikt peka på en annan tag än den tjänsten följer. CI kan till exempel säga "`1.28.0` finns" om en manuell tjänst som kör `1.27.3`. Då är förslaget inte inaktuellt utan själva poängen. Förslag: rör inte webhook-förslag i den här issuen. De töms redan av `FinishJob` när just den versionen deployas. Behöver de en egen regel, t.ex. "töm om tjänsten redan kör en tag som är lika med eller nyare än förslaget enligt `tagver`", blir det en separat issue. ## Scope - Ingår: att pollern tömmer inaktuella poll-förslag, plus tester. - Ingår inte: webhook-förslag, ändringar i `FinishJob`, `newer_*` (#11 hanterar det redan i pollern och när sidan visas).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: shcizo/package-updater#33