Batch-scoped DLQ reconciler fails requests that another live batch owns

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

Mantenedores costumam responder em até 2 dias

@burgulvedant já está trabalhando nisso.

Desde 31/10/2026.

  • #998 de @burgulvedant — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
55/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
go
Domínio
distributed-systems

Direção de pesquisa

Read dlq/request.go for the existing owningBatch guard, then trace failBatch and its batch.Contains fan-out. Add coverage for a request owned by another non-terminal batch and for the reconciled batch's own members; done means only requests not owned by another live batch are terminated.

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

Descrição

bug

Problem

The batch-scoped DLQ reconciler fails requests that another live batch owns. That batch may go on to merge the change, which leaves the request reported error for a change that lands.

How it is reached

A lost ack on the batch topic leaves two batch attempts for one request. If the redundant attempt's dependency-analysis message exhausts its retries (for example, a storage error while resolving dependencies), it dead-letters while still in creating. failBatch then moves it to failed and fans out over batch.Contains, terminating a request that reads batched and belongs to the first, healthy batch. TerminateRequest declines only when the request is already terminal, and batched is not terminal.

The guard to mirror

owningBatch in dlq/request.go already answers "which batch owns this request" for the request-scoped reconciler. The batch-scoped fan-out needs the inverse: skip a request when some other non-terminal batch owns it. The guard must exclude the batch being reconciled, or the batch counts as its own members' owner and the fan-out never happens.

Found in review of #590. As of 6c050082 the fan-out in failBatch has no ownership guard.

Linguagem predominante
Go
Estrelas
252
Forks
16
Merge médio
2d 1h
PRs com merge (30d)
125

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 uber/submitqueue

Todas as issues de uber/submitqueue

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.