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

Aperta
  • Qualcosa non va?
#4,232 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
backend, distributed-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Rust
Stelle
5.2k
Fork
502
Merge medio
3g 8h
PR unite (30g)
146

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/iggy

Tutte le issue di apache/iggy

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.