spring-cloud / spring-cloud/spring-cloud-stream
Better error handling support for reactive functions
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 646
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 8
Description
I'm using the new functional approach with RabbitMQ and strive for fully reactive message handling.
When using a reactive consumer, any error will break the connection.
What I'd like instead is, if any exception/Flux.error() happens, the RabbitMQ should retry/publish message to dlq.
Considering the following example:
@Bean
fun addAccount(dispatcher: ...): Consumer<Flux<Message<String>>> = Consumer {
it.flatMap { mono { dispatcher.handle(it) } }
.onErrorContinue { ex, _ ->
StaticMessageHeaderAccessor.getAcknowledgmentCallback(...)?.noAutoAck()
}.subscribe()
}
I understand, that I have to handle errors manually, maybe sending a manual ack/nack or requeue requests. When using non reactive logic this is provided out of the box. It would be nice if I could achieve the same behavior with an error handler in the reactive chain. The above example doesn't work as there is no ACKNOWLEDGMENT_CALLBACK in the message (that's added in non reactive case).
Any solution that achieves "retry on error" behaviour would be nice.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the reactive consumer example and the reported absence of an acknowledgment callback, then compare its error behavior with the non-reactive RabbitMQ path. Done means an exception or Flux.error() can trigger retry or dead-letter publication without breaking the connection, with the behavior covered by an appropriate test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rabbitmq, spring
- Domain
- backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100