diegomrsantos opened a new issue, #4233: URL: https://github.com/apache/iggy/issues/4233
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 E. Use [Kafka Connect's sink contract](https://kafka.apache.org/37/javadoc/org/apache/kafka/connect/sink/SinkTask.html) and Iggy's existing source acknowledgment work in [#3855](https://github.com/apache/iggy/pull/3855) as references. The decision should extend the existing discussions and explain which implementation approach is selected. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
