Community events are applied by the privileged users on latest known CommunityDescription. Control node processes community events only if they were applied on most recent CommunityDescription. Obviously, there are no guarantees that latest known CommunityDescription by privileged users is the same as control's node most recent. This could lead to an issue where community events are rejected by control node and never applied. The mechanism to mitigate that is to notify privileged users about rejected events so that they can re-apply them and send again on updated CommunityDescription. This seems to work fine at first but it can lead to ping-pong of reject event <-> resend event and effectively lead to CommunityDescription being changed and distributed over the network very frequently. The issue is most likely to happen when control node is offline for a bit.
For simplicity sake, let's assume the messages sent over the network are delivered in order and that messages are sent only between control node and one admin.
| time | action | CN CD clock | CN message | admin CD clock | admin events | admin message |
|---|---|---|---|---|---|---|
| 1 | control node creates community | 1 | CommunityDescription(1) | - | - | - |
| 2 | admin receives CD(1) | 1 | - | 1 | - | - |
| 3 | admin creates event | 1 | - | 1 | E1 | CommunityEventsMessage(1) |
| 4 | control node receives EM(1) & applies it | 2 | CommunityDescription(2) | 1 | E1 | - |
| 5 | admin receives CD(2) | 2 | - | 2 | - | - |
| 6 | control node goes offline | 2 | - | 2 | - | - |
| 7 | admin creates event | 2 | - | 2 | E2 | CommunityEventsMessage(2) |
| 8 | admin creates event | 2 | - | 2 | E2,E3 | CommunityEventsMessage(3) |
| 9 | admin creates event | 2 | - | 2 | E2,E3,E4 | CommunityEventsMessage(4) |
| 10 | control node goes back online | 2 | - | 2 | E2,E3,E4 | - |
| 11 | control node receives EM(2) & applies it | 3 | CommunityDescription(3) | 2 | E2,E3,E4 | - |
| 12 | control node receives EM(3) & rejects it | 3 | CommunityEventsMessageRejected(1) - E2,E3 | 2 | E2,E3,E4 | - |
| 13 | control node receives EM(4) & rejects it | 3 | CommunityEventsMessageRejected(2)- E2,E3,E4 | 2 | E2,E3,E4 | - |
| 14 | admin receives CD(3) | 3 | - | 3 | - | - |
| 15 | admin receives EMR(1) & re-applies events | 3 | - | 3 | E2,E3 | CommunityEventsMessage(5) |
| 16 | admin receives EMR(2) & re-applies events | 3 | - | 3 | E2,E3,E4 | CommunityEventsMessage(6) |
| 17 | control node receives EM(5) & applies it | 4 | CommunityDescription(4) | 3 | E2,E3,E4 | - |
| 18 | control node receives EM(6) & rejects it | 4 | CommunityEventsMessageRejected(3)- E2,E3,E4 | 3 | E2,E3,E4 | - |
| 19 | admin receives CD(4) | 4 | - | 4 | - | - |
| 20 | admin receives EMR(3) & re-applies events | 4 | - | 4 | E2,E3,E4 | CommunityEventsMessage(7) |
| 21 | control node receives EM(5) & applies it | 5 | CommunityDescription(5) | 4 | E2,E3,E4 | - |
| 22 | admin receives CD(5) | 5 | - | 5 | - | - |
CN - control node CD - community description EM - events message EMR - events message rejected
As illustrated in above table, when control node is offline and one admin creates 3 separate events at that time, it may result in 3 CommunityDescription updates, 6 CommunityEventsMessage and 3 CommunityEventsMessageRejected. Now imagine what would happen if there are few admins with many pending events each.
The above is especially problematic when a privileged user performs similar actions in different events. For instance, the UI allows privileged users to change their decision when it comes to accepting or rejecting requests to join. Let's say an admin accepts a user, then mistakenly rejects them, and subsequently accepts them again. Since the events will most likely be processed in order, the user will receive three notifications: accepted into the community, rejected from the community, and accepted into the community again.
Mitigation proposal: https://github.com/status-im/status-desktop/issues/13388