[shinydevops]

Hopefully I'm not misunderstanding your use case, but I would think you could accomplish this by publishing a durable message to a highly available, durable queue with no consumers, setting a TTL on the message with a policy to publish to a "dead letter exchange" that fronts the queue or queues with your eventual consumers. The durability flags ensure both message and queue survive a restart, while the high availability policy on the queue ensures that each node in the cluster has a copy. And I'm sure there are a few similar patterns that would garner the same desired behavior.

I'm not taking a position on whether this is an acceptable level of complexity for the desired feature, of course, just pointing out how one might accomplish it if Rabbit is otherwise desirable.