Major Description
-
- Reproduction steps:
Given a bad payload published on the mailQueue exchange
Then the dequeuer will crash and stop any following dequeuing processing
-
- Consequences:
This can be leveraged to knock down mail reception given only the right to publish messages to RabbitMQ.
This can generate problems to users when upgrading with non-empty mailqueue upon MailReferenceDTO changes
-
- Alternatives
To not be crashing, we actually need to handle the deserialization exception.
Dropping the message would be a quick fix, but could result in data loss.
A better alternative would be to leverage a dead-letter queue in order to enable to not abort processing, while keeping track of the failure, and allowing to resume its processing.
-
- Related issues
We are considering improving the reliability of the distributed mailqueue component, and allow to drop all RabbitMQ content. To recover from such a situation, non-dequeued emails would be tracked using the Cassandra browsing projection, and requeued in a newly provisionned rabbitMQ.
Given the ability to re-generate non - dequeued entries, dropping invalid rabbitMQ messages could be acceptable, as the admins will have the right tools to re-generate legitimate traffic.