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

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

Maintainer antworten meist innerhalb von 2 Tagen

@burgulvedant arbeitet bereits daran.

Seit 31.10.2026.

  • #998 von @burgulvedant — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
go
Bereich
distributed-systems

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Go
Sterne
252
Forks
16
Ø Merge
2 T. 1 Std.
Gemergte PRs (30 T.)
125

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

Alle Issues in uber/submitqueue

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

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