%% This Source Code Form is subject to the terms of the Mozilla Public
%% License, v. 2.0. If a copy of the MPL was not distributed with this
%% file, You can obtain one at https://mozilla.org/MPL/2.0/.
%%
%% Copyright (c) 2017-2022 VMware, Inc. or its affiliates. All rights reserved.
%%
%% @doc The `ra_machine' behaviour.
%%
%% Used to implement the logic for the state machine running inside Ra.
%%
%% == Callbacks ==
%%
%% -callback init(Conf :: {@link machine_init_args()}) -> state()'
%%
%% Initialize a new machine state.
%%
%%
%% -callback apply(Meta :: command_meta_data(),
%% {@link command()}, State) ->
%% {State, {@link reply()}, {@link effects()}} | {State, {@link reply()}}
%%
%% Applies each entry to the state machine.
%%
%%
%%
%% -callback state_enter(ra_server:ra_state() | eol, state()) -> effects().
%%
%%
%% Optional. Called when the ra server enters a new state. Called for all states
%% in the ra_server_proc gen_statem implementation not just for the standard
%% Raft states (follower, candidate, leader). If implemented it is sensible
%% to include a catch all clause as new states may be implemented in the future.
%%
%%
%% -callback tick(TimeMs :: milliseconds(), state()) -> effects().
%%
%%
%% Optional. Called periodically.
%% Suitable for issuing periodic side effects such as updating metrics systems.
%%
%%
%% -callback overview(state()) -> map().
%%
%% Optional. A map of overview information. Needs to be efficient.
%%
%%
%%
%%
%% -callback version() -> version().
%%
%%
%% Optional: Returns the latest machine version. If not implemented this is
%% defaulted to 0.
%%
%%
%%
%% -callback which_module(version()) -> module().
%%
%%
%% Optional: implements a lookup from version to the module implementing the
%% machine logic for that version.
-module(ra_machine).
-compile({no_auto_import, [apply/3]}).
-include("ra.hrl").
-export([init/2,
apply/4,
tick/3,
state_enter/3,
overview/2,
query/3,
module/1,
init_aux/2,
handle_aux/7,
snapshot_module/1,
version/1,
which_module/2,
is_versioned/1
]).
-type state() :: term().
%% The state for a given machine implementation.
-type user_command() :: term().
%% the command type for a given machine implementation
-type machine_init_args() :: #{name := atom(), atom() => term()}.
%% the configuration passed to the init callback
-type machine() :: {machine, module(), AddInitArgs :: #{term() => term()}}.
%% Machine configuration.
%% the `module()' should implement the {@link ra_machine} behaviour.
-type milliseconds() :: non_neg_integer().
-type builtin_command() :: {down, pid(), term()} |
{nodeup | nodedown, node()} |
{timeout, term()}.
%% These commands may be passed to the {@link apply/2} function in reaction
%% to monitor effects
-type send_msg_opt() :: ra_event | cast | local.
%% ra_event: the message will be wrapped up and sent as a ra event
%% e.g: `{ra_event, ra_server_id(), Msg}'
%%
%% cast: the message will be wrapped as a gen cast: ``{'$cast', Msg}''
%% local: the message will be sent by the local member if there is one
%% configured
-type send_msg_opts() :: send_msg_opt() | [send_msg_opt()].
-type locator() :: pid() | atom() | {atom(), node()}.
-type version() :: non_neg_integer().
-type effect() ::
{send_msg, To :: locator(), Msg :: term()} |
%% @TODO: with local deliveries is it theoretically possible for a follower
%% to apply entries but not know who the current leader is?
%% If so, `To' must also include undefined
{send_msg, To :: locator(), Msg :: term(), Options :: send_msg_opts()} |
{mod_call, module(), Function :: atom(), [term()]} |
%% appends a user command to the raft log
{append, term()} |
{append, term(), ra_server:command_reply_mode()} |
{monitor, process, pid()} |
{monitor, node, node()} |
{demonitor, process, pid()} |
{demonitor, node, node()} |
{timer, term(), non_neg_integer() | infinity} |
{log, [ra_index()], fun(([user_command()]) -> effects())} |
{log, [ra_index()], fun(([user_command()]) -> effects()), {local, node()}} |
{release_cursor, ra_index(), state()} |
{aux, term()} |
garbage_collection.
%% Effects are data structures that can be returned by {@link apply/3} to ask
%% ra to realise a side-effect in the "real world", such as sending
%% a message to a process, monitoring a process, calling a function or
%% forcing a GC run.
%%
%% Although both leaders and followers will process the same commands, effects
%% are typically only applied on the leader. The only exception to this is
%% the `release_cursor' and `garbage_collect' effects. The former is realised on all
%% nodes as it is a part of the Ra implementation log truncation mechanism.
%% The `garbage_collect' effects that is used to explicitly triggering a GC run
%% in the Ra servers' process.
%%
%% When the leader changes and when the cluster is restarted, there is a small chance
%% that effects are issued multiple times so designing effects with idempotency
%% in mind is a good idea.
%%
%%
%%