Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

retrymq limit & DLQ

Đang mở
  • Có gì không ổn?
#663 9 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
30/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
go
Lĩnh vực
distributed-systems

Hướng nghiên cứu

Start by locating the retry task executor and the queue handling that uses receive count and the 30-second visibility timeout; compare its configuration with deliverymq. Resolve the open questions about the receive limit, backoff, DLQ behavior, and configuration before implementation. Done means repeated internal failures are capped and stuck messages can be surfaced or replayed, with behavior configurable as agreed.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

When a retry task's executor fails (e.g., event not found in logstore, transient errors), the message sits in the queue and becomes visible again after a fixed 30s visibility timeout. This repeats indefinitely with no limit.

Problems

  • A permanently failing retry message cycles forever with no cap
  • No dead-letter path to detect or surface stuck messages
  • Fixed visibility timeout on re-fetch failures — no backoff between attempts

The underlying queue already tracks receive count and supports per-message visibility changes, so the primitives are there.

Open questions

Max receive count

What should the default be?

Suggestion: 5 internal re-fetch attempts before giving up. This is separate from the delivery retry max limit, which controls how many times we re-deliver to the destination.

Backoff on re-fetch

Should we apply exponential backoff on internal failures (e.g., 30s → 60s → 120s), or is a fixed interval fine since these are typically short-lived transient issues?

What happens when max is exceeded

Suggestion: Route to a DLQ. Gives observability into stuck messages and the ability to replay them.

Configuration

Suggestion: Expose as retrymq config, similar to how deliverymq is configured. e.g., RETRYMQ_MAX_RECEIVE_COUNT, RETRYMQ_VISIBILITY_TIMEOUT_SECONDS.

Ngôn ngữ chính
Go
Star
1.1k
Fork
70
Merge trung bình
1 ngày 18 giờ
Pull request đã merge (30 ngày)
56

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của hookdeck/outpost

Tất cả issue của hookdeck/outpost

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.