connectors: define the sink delivery and recovery contract

Aperta
  • Qualcosa non va?
#4,233 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
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
kafka, rust
Ambito
api, distributed-systems

Direzione di ricerca

Start by reading parent tracker #4232, Kafka Connect's SinkTask contract, Iggy's source acknowledgment work in #3855, and the failure scenarios in #4237. Document the selected delivery, checkpoint, retry, lifecycle, filtering, versioning, and migration behavior, including expected outcomes for each scenario. Done means the observable contract and chosen implementation approach are recorded and can be used to judge correctness.

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

Descrizione

connectors

Parent tracker: #4232.

Agree on the behavior the runtime and sink plugins must provide before selecting the API shape. The design should make it possible to determine whether an implementation is correct from its observable behavior.

Acceptance criteria:

  • Define the destination acknowledgment required for a record to count as delivered, including buffering, partial success, and uncertain outcomes.
  • Specify the checkpoint rule per partition, including whether offsets identify the last completed record or the next record to process. Define duplicate behavior, the supported ownership model, and source durability and retention assumptions.
  • Choose an acknowledgment mechanism that identifies the records it covers. A serialized flush barrier is acceptable if its completion proves delivery of the entire covered set.
  • Define retry responsibility, failure isolation, shutdown, restart, and assignment changes. Document unsupported concurrency where necessary.
  • Define intentional filtering and the treatment of unexpected pipeline failures.
  • Agree on API versioning, capability checks, defaults, and migration.
  • Record expected outcomes for the failure scenarios used by #4237.

Use Kafka Connect's sink contract and Iggy's existing source acknowledgment work in #3855 as references. The decision should extend the existing discussions and explain which implementation approach is selected.

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

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.