Rolling upgrade: GitHub default-branch adoption can miss the first sync or an older replica's PATCH to main (#599 follow-up)

Offen
  • Stimmt etwas nicht?
#609 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@ThomasK33 arbeitet bereits daran.

Seit 06.11.2026.

  • #702 von @ThomasK33 — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
20/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
github, go
Bereich
backend, devops

Rechercherichtung

Read PR #607 and the two rolling-upgrade cases described here, then inspect the relevant sync and PATCH handling code and its tests. Decide how to prevent both missed adoption and an older replica's explicit PATCH from being overwritten; verify the behavior for each case. The issue names no source files or test paths, so locate them from the PR.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Problem

PR #607 adopts the GitHub default branch at a successful sync of a GitHub sync repo whose create omitted default_branch (#599). During a rolling upgrade from a release without this rule, two cases miss the upstream behavior. http-api.md documents both, and the PR's Codex round 1 raised both.

  1. A sync that an older worker runs does not adopt. The flag stays set, so the next sync by an upgraded worker adopts. Until that sync, the repo is on main, and with no further trigger it stays there.
  2. An older replica's PATCH /repo to main before that sync writes nothing that differs from the create's placeholder main. The next sync by an upgraded worker then replaces the caller's explicit main with the GitHub branch. A PATCH to any other branch is kept, because the adopt write requires the repo to still be on main.

Possible fixes

  • A fleet-version gate, like OPENSTORAGE_SYNC_STEAL_LEGACY: an operator assertion that no older replica remains before creates set the flag.
  • A reconciliation sweep that schedules a sync for flagged repos with success_count > 0. This covers case 1 only.
  • Deploy sequencing in the release notes: upgrade every replica before accepting GitHub sync creates.

Trigger

Act on this issue at the first report of a GitHub sync repo left on main after a rolling upgrade, or when a release that ships #607 is prepared (decide then whether the release notes need a sequencing note).

Refs #599

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

Vorherrschende Sprache
Go
Sterne
0
Forks
0
Ø Merge
6 Std. 16 Min.
Gemergte PRs (30 T.)
243

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus coder/openstorage

Alle Issues in coder/openstorage

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.