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

Abierto
  • ¿Algo no está bien?
#4,232 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@numinnex ya está trabajando en esto.

Desde el 3/11/2026.

  • #4739 de @numinnex — abierto
  • #4740 de @numinnex — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
rust
Área
backend, distributed-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
5.2k
Forks
502
Merge medio
3 d 5 h
PR fusionados (30 d)
152

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/iggy

Todos los issues de apache/iggy

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.