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

Aberta
  • Algo errado?
#609 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@ThomasK33 já está trabalhando nisso.

Desde 6/11/2026.

  • #702 de @ThomasK33 — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
20/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
github, go
Domínio
backend, devops

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Go
Estrelas
0
Forks
0
Merge médio
6h 16min
PRs com merge (30d)
243

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de coder/openstorage

Todas as issues de coder/openstorage

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.