Major Description
= Why
Following this ADR https://github.com/apache/james-project/pull/248
Mailbox inconsistencies requires manual intervention of the admin (via the solve-inconsistency webadmin endpoint) to be resolved.
Having such task to ensure a correct denormalisation state is desirable, but optimally we should not have to rely on the admin to remember running it.
We would prefer an auto-healing solution
= Context
Read repair is a classic mechanism in eventual consistent databases (like cassandra) to piggy back consistency healing operation upon reads.
A fraction of the reads will have a wider reach, read more data, and ensure it is correctly replicated.
Cassandra eventual consistency is all about "replication", but "denormalization" consistency needs to be handled at the applicative layer. In the past we did set up "Solve inconsistency" tasks that can be assimilated to Cassandra repairs. In order to achieve denormalization auto-healing, we thus needs to implement "applicative read repairs".
= Technically speaking
Upon reads, for each mailbox, the mailbox mapper have a configurable random chance to trigger read repairs.
In this case both table are read, and the "solve inconsistency" mechanism is applied, if needed.
Write unit tests demonstrating this "solve inconsistency" behaviour.
Also read repairs are the missing bit to make the "read only mailboxPath" optimization viable: development needs to happen on top of https://github.com/linagora/james-project/pull/3635 ` POC Denormalize UidValidity as part of MailboxPath projection` branch
= Definition Of Done
Record a video :
- Given a read repair chance of 0.2 (20%)
- There is a mailbox inconsistency (no OUTBOX) - (remove the mailbox entry manually in cassandra)
- The user does many requests - after some time, the inconsistency is fixed: he has an OUTBOX again!
As an admin, I should be able to configure (or disable) the read-repair-chance for the mailbox entity