Tracking: establish at-least-once delivery for sink connectors

Đang mở
  • Có gì không ổn?
#4,232 0 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
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
backend, distributed-systems

Hướng nghiên cứu

Start with the proposed work items #4233–#4238 and the local HTTP regression sequence described here. Read #2928, discussions #3203 and #3518, and PRs #3954 and #4152 to understand existing decisions and work. Done requires an agreed contract, linked implementation and recovery tests, supported configurations, and migration and operational documentation.

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

Mô tả

connectors

I propose tracking the remaining sink delivery work under one agreed contract, with separate implementation issues and recovery tests as acceptance criteria.

The runtime can save a consumer offset before the sink delivers the corresponding records. If delivery fails, restarting with the same consumer group can skip those records. They may remain in Iggy's retained log, but normal recovery does not deliver them.

A local HTTP regression test reproduces this sequence: the endpoint rejects a record with HTTP 503, the runtime restarts with the same consumer group after the endpoint recovers, and a later record arrives while the rejected record does not. This test covers rejection followed by restart; abrupt termination needs additional coverage.

Issue #2928 and discussions #3203 and #3518 already describe the underlying problem and proposed approaches. PR #3954, by kriti-sc, adds control over commit timing and provides implementation work to build on. PR #4152 has since improved failure reporting and accounting, but explicitly does not introduce batch replay. The status of #2927 should be reconciled with that merged work.

The proposed contract is:

For each partition, the runtime advances the recovery checkpoint only after every record it passes has satisfied the configured delivery contract, including all required destination writes. Failed or uncertain delivery remains recoverable. Recovery may produce duplicates.

Acceptance into a plugin's memory buffer must be distinct from durable delivery. Unexpected decode, transform, and serialization failures must remain unresolved until recovered or handled by an explicit policy. A configured filter is a separate outcome. If a dead-letter policy is supported, its write must succeed before the checkpoint advances, and the resulting guarantee must name that alternative destination.

Each supported sink configuration must define what its delivery acknowledgment proves. The contract also depends on source durability, sufficient retention, and eventual recovery. Missing replay data must produce a visible recovery failure.

Proposed work:

  • #4233: Define the sink delivery and recovery contract.
  • #4234: Implement explicit sink delivery acknowledgments and safe checkpoint advancement.
  • #4235: Preserve failed records throughout the sink pipeline.
  • #4236: Migrate sink plugins and document supported configurations.
  • #4237: Add a shared recovery conformance suite.
  • #4238: Introduce safe defaults, migration guidance, and operational visibility.

Existing issues and PRs should be linked to these work items where their scope matches. The test suite should begin alongside the contract work, with regression coverage included in each implementation change.

This tracker is complete when the agreed delivery contract is enforced for every configuration advertised as supporting it, incompatible configurations fail explicitly, required recovery tests pass in CI, and the migration and operational documentation are available.

Maintainer feedback is requested on the target contract, the initial set of supported sinks, the interface migration, and how to continue the work in #3954.

Ngôn ngữ chính
Rust
Star
5.2k
Fork
502
Merge trung bình
3 ngày 11 giờ
Pull request đã merge (30 ngày)
143

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

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

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 apache/iggy

Tất cả issue của apache/iggy

Issue tương tự

Thêm issue về Rust

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.