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

Open
#824 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Go
Stars
247
Forks
16
Avg merge
2d 1h
Merged PRs (30d)
125

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from uber/submitqueue

All issues in uber/submitqueue

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.