Artem Bilan

I would say we can't make such an unconditioanl decision in the framework and some customized `RetryPolicy` is the way to go. We definitely may provide some out-of-the-box `RetryPolicy` based...

Good. So, feel free to contribute such a custom `RetryPolicy`!

See my comment in your PR: https://github.com/spring-projects/spring-amqp/pull/1287#issuecomment-748203972 We can't apply your change or consider as a bug, since it works like that for any existing `@...Listener` solution. So, we need...

OK, sorry. I see you have created a similar issue for Spring Kafka: https://github.com/spring-projects/spring-kafka/issues/1704. So, yeah, you probably just pointing for the common problem everywhere. This is not a new...

@garyrussell , isn't this fixed now via: https://github.com/spring-projects/spring-amqp/issues/1444?

Agreed. This is really a valid requirement. We have a logic like this already: ``` JavaUtils.INSTANCE // NOSONAR .acceptIfNotNull(this.beforeSendReplyPostProcessors, messageListener::setBeforeSendReplyPostProcessors) ``` where the mentioned `replyPostProcessor` is really a property of...

Yes, but it also could be done by the `BaseRabbitListenerContainerFactory` as a common place for such a property. The `@RabbitListener` one can override, of course.

I think `this.converter.toOutbound()` should produce a `Mono` do not have it in a blocking state, but just let it to be evaluated later on demand during subscription. Looks like the...

Hi @vavrfam ! Thank you for your interest in the feature. Yes, plans are build something in Spring AMQP based on the `reactor-rabbitmq`. And yes such a feature definitely can...

See my comment here: https://github.com/spring-cloud/spring-cloud-sleuth/issues/1663#issuecomment-748196310