A successfully acked message is redelivered long before its visibility timeout expires

Offen
#824 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

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

Rechercherichtung

Start by tracing the message ack and visibility-timeout delivery paths, then inspect how delivery-state rows are updated and garbage-collected. Reproduce the reported redelivery under load and compare the stored ack state and invisible_until with the configured 60-second timeout. Done means identifying and fixing the cause so a successfully acked message is not redelivered before its visibility timeout.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug

Problem

A message that a consumer processed successfully, and reported as processed, was redelivered about 12 seconds later, against a 60-second visibility timeout and with a single consumer running. The redelivery reported attempt: 2, so it came through the visibility-timeout path on a delivery-state row that was still unacked.

Impact

The duplicate propagated: Runway answered the same merge-conflict-check twice, and the batch stage created a second batch for the same request. The pipeline absorbed it, and the duplicate batches failed, but each one cost a full speculation and build cycle. If a successful ack can be redelivered at a fifth of its visibility timeout, at-least-once delivery is firing far more often than intended.

Not yet established

Either the ack did not set acked, despite the consumer reporting success, or invisible_until was shorter than configured. The delivery-state row had already been garbage-collected, so it could not be inspected. This reproduced under load (a 20-request demo run) and not on smaller runs.

Status

No fixing change has been identified on main.

Vorherrschende Sprache
Go
Sterne
247
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.