Использование TestChannelBinderConfiguration, но два обработчика регистрируются

У меня есть приложение Spring Cloud Stream, которое обрабатывает события (кредитные карты), некоторые из которых обрабатываются синхронно, а некоторые асинхронно. В Котлине я придумал примерно следующее:

весеннее облако-стартер-ручей-кролик = 3.1.0

@Service
class CardEventProcessor(
    private val streamBridge: StreamBridge,
) : Consumer<AsyncCardEvent> {

    fun process(cardEvent: SyncCardEvent): Result { return businessLogic() }

    fun processAsynchronously(cardEvent: AsyncCardEvent) {
        streamBridge.send("cardEventProcessor-out-0", cardEvent)
    }

    override fun accept(cardEvent: AsyncCardEvent) { businessLogic() }
}

и настроили его так:

  rabbitmq: ...
  cloud:
    stream:
      bindings:
        cardEventProcessor-in-0:
          destination: cardevents
          group: CardEventProcessor
        cardEventProcessor-out-0:
          destination: cardevents

Кажется, все работает нормально, за исключением интеграционных тестов, обработка которых завершается сбоем после второго события асинхронной карты. Мне удалось отладить / уменьшить проблему до двух обработчиков, зарегистрированных в UnicastingDispatcher, который имеет циклическую стратегию: один для TestChannelBinder, а другой для OutputDestination $ lamdba.

Вот как выглядит мой класс интеграционного теста:

@SpringBootTest
@Transactional
@AutoConfigureMockMvc
@AutoConfigureEmbeddedDatabase
@Import(TestChannelBinderConfiguration::class)
class IntegrationTests {

    @Test
    fun `Use case one`() {
        sendFirstAsyncRequest()  // processed correctly in CardEventProcessor.accept()
        sendSecondAsyncRequest() // message never arrives in CardEventProcessor.accept()
    }
}

Я следил за разделом «Тестирование» в документации Spring Cloud Stream и не могу понять, что мне не хватает, чтобы это работало. В примере есть функция ‹›, а не потребитель ‹›, и я создаю в том же классе @Service, что и потребитель (потому что очередь - это просто деталь реализации для решения асинхронности, а не типичный вариант использования очередей между микросервисами) но насколько я понимаю, это должно работать, и действительно работает, когда не выполняется в качестве интеграционного теста.

Я видел Отключить Spring Cloud Stream Rabbit для тестов, но не хотел зависеть от устаревшего spring-cloud-stream-test-support, и два других предложения тоже не сработали. Любые идеи?