I would like the RabbitMQ event bus to keep events that are published while the broker is unreachable and deliver them, in order, once the connection is back, within configurable limits (number of events and maximum
age).
As we tested during the network outage, every event that is published while the broker is unreachable is lost.
At the moment it works like that events are sent with without publisher confirms, so when the connection is down, the event is discarded.
The reconnect logic restores the connection only and nothing is replayed:
when publish() catches AlreadyClosedException it calls closeConnection().
That shutdown is application initiated, so DisconnectHandler ignores it and no
ReconnectionTask is started. The next publish() then connects on the calling thread, which can block for up to the client's connection timeout if the host does not answer.
Another observation - the RabbitMQ client reports any connection close it did not initiate as "shutdown by AMQP server", including closes by a load balancer idle timeout.
Also it seems, the current code has no confirmation mechanism, so we never know the messages really reached the AMQP.
Proposal
Keep events that cannot be sent in a bounded in-memory FIFO buffer and send
them in order after the reconnect.
Two optional properties on the existing event bus bean: maximum number of
buffered events (default 1000, oldest dropped first) and maximum age of a
buffered event (default 5 minutes).
Buffer only after the broker was reachable at least once; before that keep
today's behavior.
threat detection engine error
The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
What happened
The threat detection engine failed to produce results.
The request is for the RabbitMQ event bus to buffer events published while the broker is unreachable, in a bounded in-memory FIFO (default 1000 events, 5 minute maximum age), and to send them in order after reconnect. The reporter says events are currently dropped, because publishing is not confirmed and publish() closes the connection without starting the reconnect task. A pull request (#14677) implementing a buffer is already open.
📊 Assessment
Dimension
Value
Reasoning
Type
type:new-feature
Requests new buffering behaviour; no crash reported
Component
none
The issue text does not map to a component label
Severity
n/a
Not a bug report
Labels
type:new-feature
Based only on the issue text
Coding agent
Not suitable
Buffer semantics (ordering, drop policy, startup behaviour) need maintainer review; PR #14677 is already open
Review Rabbitmq eventbus buffer implementation #14677 against the proposal, in particular the default limits and whether buffering starts only after the first successful connection, as proposed.
The reporter also raises two separate points: the AlreadyClosedException path that closes the connection without a reconnect, and publisher confirms. Those may need their own items if they are not covered by Rabbitmq eventbus buffer implementation #14677.
Activity
rabbitmq event bus: buffer events while the broker is unreachable
github-actions commented on Nov 12, 2026
Warning
threat detection engine error
What happenedThe threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
The threat detection engine failed to produce results.
Review the workflow run logs for details.
🎯 Triage report
The request is for the RabbitMQ event bus to buffer events published while the broker is unreachable, in a bounded in-memory FIFO (default 1000 events, 5 minute maximum age), and to send them in order after reconnect. The reporter says events are currently dropped, because publishing is not confirmed and publish() closes the connection without starting the reconnect task. A pull request (#14677) implementing a buffer is already open.
📊 Assessment
🔗 Similar issues
- NPE found when rabbitmq event bus is configured with cloudstack #12634 (related, closed) — NPE when the RabbitMQ event bus is configured
- Event Notifications not working over Event Bus for Kafka or RabbitMQ Configurations #7589 (related, closed) — event notifications not working over Kafka or RabbitMQ
💡 Notes and suggestions- Review Rabbitmq eventbus buffer implementation #14677 against the proposal, in particular the default limits and whether buffering starts only after the first successful connection, as proposed.
- The reporter also raises two separate points: the AlreadyClosedException path that closes the connection without a reconnect, and publisher confirms. Those may need their own items if they are not covered by Rabbitmq eventbus buffer implementation #14677.
Add this agentic workflow to your repoTo install this agentic workflow, run