You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ra_server_proc: Fix handling of local query replies
[Why]
The reply of local query was formatted as:
{reply, From, Reply}
However, the code was called in two different contexts:
1. When the local query was executed immediately, the reply tuple was
interpreted by `gen_statem` and thus the reply was sent by the local
Ra server process. Exactly what we wanted.
2. When the local query execution depended on a condition and might have to be
delayed, it could be executed right away (and the reply tuple was
interpreted by `gen_statem`), or the execution could be delayed and
at the time of execution, the reply tuple could be interpreted as a
Ra effect.
Unfortunately, the same tuple has a very different meaning depending on
who interprets it:
* `gen_statem` will send the reply regardless of the Raft state of the
Ra server process.
* The Ra effect will only send the reply if the Ra server process is
acting as the leader.
The delayed query was always processed by the Ra server that received
it, regardless of its state. This means that if the Ra server is not a
leader and the reply tuple is interpreted as a Ra effect, the caller
will never get an answer.
This led to some timeouts in Khepri and nasty bugs in RabbitMQ. In
particular, it caused the `peer_discovery_classic_config_SUITE` to fail
quite frequently in RabbitMQ CI.
[How]
First, the patch ensures the reply tuple is always interpreted as a Ra effect.
Then, it sets the `{member, ...}` replier option in the reply effect to
the Ra server that executes the query. This way, the reply is always
emitted emitted and by the correct Ra server, regardless of its Raft
state.
0 commit comments