[FIXED] only UpdateDelivered with quorum when clustered#6139
[FIXED] only UpdateDelivered with quorum when clustered#6139derekcollison merged 1 commit intomainfrom
UpdateDelivered with quorum when clustered#6139Conversation
Signed-off-by: Maurice van Veen <github@mauricevanveen.com>
MauriceVanVeen
changed the title
UpdateDelivered with quorum when clusteredUpdateDelivered with quorum when clustered
derekcollison
left a comment
derekcollison
left a comment
There was a problem hiding this comment.
This was by design we would not wait on quorum to deliver messages to consumers.
This one also warrants a discussion IMO prior to a PR.
|
For what it's worth I think this type of change makes sense. Quorum is what aligns the leader with the followers. If we're making persistent changes to the state of an asset without going through the Raft apply queue, then we've undermined the point of running Raft in the first place and then all bets are completely off when the leader changes. |
|
Like I said better to discuss on a call / video. |
|
@derekcollison , I've marked this PR ready for review as well. We've discussed that only the |
`store.UpdateDelivered` would always be called, without checking quorum. Which meant that we could get a consumer to be ahead on delivered after switching leader. This change makes `o.updateDelivered` consistent with `o.updateAcks`, which does the same; if clustered propose through RAFT, if not just update delivered directly. Signed-off-by: Maurice van Veen <github@mauricevanveen.com>
3 participants
store.UpdateDeliveredwould always be called, without checking quorum. Which meant that we could get a consumer to be ahead on delivered after switching leader. This change makeso.updateDeliveredconsistent witho.updateAcks, which does the same; if clustered propose through RAFT, if not just update delivered directly.Signed-off-by: Maurice van Veen github@mauricevanveen.com