SpringBoot中@KafkaListener返回void却用CompletableFuture的行为咨询

@KafkaListener(
        topics = "${kafka.consumers.foo.schema.topicName}",
        groupId = "${spring.kafka.group-id}",
        autoStartup = "${kafka.consumers.foo.autoStartup}",
        concurrency = "${kafka.consumers.foo.concurrency}",
        containerFactory = "kafkaListenerContainerFactory"
)
public void consumeEvent(final ConsumerRecord<String, SteamBoatEntity<DomainEvents>> events) {
    final DomainEvents event = events.value().record;
    final int action = event.getAction();

    CompletionStage<Void> result = switch (action) {
        case EventAction.CREATE -> onCreate(event);
        case EventAction.UPDATE -> onUpdate(event);
        case EventAction.DELETE -> onDelete(event);
        default -> completedStage(null);
    };

    result.whenComplete((unused, ex) -> {
        if (ex != null) {
            logger.error("Error handling event: {}", ex.getMessage(), ex);
        }
    });
}

上述示例中，@KafkaListener方法返回类型为void，内部使用CompletableFuture但未调用.join()，与Spring Kafka文档中返回CompletableFuture的异步处理方式不同。现咨询：

1. 当前设置是否会导致同时处理过多事件，能否保证消息的处理与确认顺序；
2. 若后续添加重试逻辑，发生异常时该@KafkaListener是否会执行重试。

1. 并发处理与消息顺序问题 #

• 这种写法会导致同一分区下的消息被并发处理：因为@KafkaListener返回void时，Spring Kafka会认为当前消息处理已完成，立刻推进偏移量（自动提交或批量提交模式下）并拉取下一条消息，而内部的CompletableFuture异步任务会在后台独立执行，主线程不会等待其完成。
• 无法保证消息处理与确认的顺序一致性：同一分区的消息原本按消费顺序依次处理，但现在前一条消息的异步任务可能还未完成，下一条消息已经开始处理，最终任务执行结果的顺序可能和消息消费顺序脱节；同时偏移量是在主线程返回后就提交，即使后续异步任务失败，也无法回滚已提交的偏移量。
• 同时处理的事件数量会不受控：除了concurrency配置的消费者线程数，每个线程内部的异步任务还会依赖自身线程池的并发能力，如果线程池没有限制，很容易出现大量异步任务同时运行，引发资源耗尽风险。

2. 重试逻辑的有效性 #

• 默认Spring Kafka重试机制不会生效：因为@KafkaListener方法已经正常返回void，没有向容器抛出任何异常，Spring Kafka会判定消息处理成功，不会触发重试流程。
• 即使异步任务抛出异常，也只会在whenComplete中被日志记录，不会向上传递给Spring Kafka容器，容器无法感知到处理失败，自然不会执行重试。
• 要让重试生效，有两种可行方式：
  • 将@KafkaListener方法的返回类型改为CompletableFuture<Void>，让Spring Kafka直接感知异步任务的状态；
  • 在异步任务执行后调用.join()，将异常抛出到主线程，让容器捕获到失败，但这样会失去异步处理的优势。

内容的提问来源于stack exchange，提问作者user6800688