Does an asynchronous return type in a @KafkaListener requires using manual ACKs?

[helpermethod]

The documentation is a little bit unclear

The AckMode will be automatically set the MANUAL and enable out-of-order commits when async return types are detected; instead, the asynchronous completion will ack when the async operation completes. When the async result is completed with an error, whether the message is recover or not depends on the container error handler. If some exception occurs within the listener method that prevents creation of the async result object, you MUST catch that exception and return an appropriate return object that will cause the message to be ack or recover.

For example, when the listener is suspend-ing, do I need to manually acknowledge?

[sobychacko]

The framework automatically sets the ack mode to MANUAL when enabling async replies. This means that the normal ack mechanisms in a regular listener are not applied here; rather, the framework manually acknowledges the record once the async processing is complete. It might look a bit confusing since MANUAL means the users are acknowledging it manually in the application and not the framework, but in the case of async replies, MANUAL means that the framework waits for the completion callback to return and then manually ack it. Therefore, you do not need to do any manual acknowledgment when the listener is suspended.

Here is the PR that made this change: https://github.com/spring-projects/spring-kafka/pull/2996/files

This section especially might be relevant: https://github.com/spring-projects/spring-kafka/pull/2996/files#diff-377d3bd2ec14091e61c082bdd64fd3881fe134f5c9bf043ac3e4f78bca2a051fR474

[helpermethod]

Thanks for the quick answer @sobychacko, that makes a lot of sense.

Another related question: are records of a batch effectively processed in parallel? We are seeing a lot of DuplicateKeyException when consecutive records contain the same primary key.

[sobychacko]

Out-of-order commits are enabled automatically when async replies are used. This means that offsets could be committed out-of-order when processing records in a listener using async replies, which implies that the records may be processed in parallel. As to the specific exception you are observing, I don't know what's going on. This is a new feature, and it could be possible that there might be some gaps. If you have a reproducible sample, we can look at it and see what's going on.