opencyphal-garage / cyraft Goto Github PK

The leader election "works", however there's a couple of small issues I'm still struggling with. Fundamentally they are all related to scheduling/cancelling the delayed callbacks (for term/election timeouts).

Running tests/raft_leader_election.py:

1. pytest -k _unittest_raft_fsm_1 --pdb

The above warning-message appears. I don't see why though. At the end I'm using cancel(); which should take care care of cancelling both callbacks:

The thing is, it does take care of cancelling those callbacks, for example if add an additional 10 seconds of sleep (expecting that if the callback was not cancelled properly it would have enough time to execute), it doesn't execute anything:

(Nothing happens.)

2. Now comes the confusing part, the previous the unit tests should indicate that the heartbeat mechanism works correctly, however it starts to mess up with the last 2 unit tests? For example running:

pytest -k _unittest_raft_fsm_3 --pdb

Even though node 43 gets the heartbeat message as expected, it resets the election timeout timer, it still somehow ends up timing out on the election timeout set at the start of the unit test?

Am I missing something?

So:

Is there any reason why we can't remove the marked state transition? After all if we assume that upon election timeout, the node returns to the follower state, basicly the same result is achieved? (It starts another election timeout, allowing for some other node to get elected in the meantime.)

This would simplify both the RaftNode implementation, as well as the testing part (where it is difficult to catch a node as it transitions between candidate and candidate state).

PS: Im gonna proceed as if the answer is yes.

I'm trying to get a response from request_vote, after sending a request using Yakut.

The issue is that I'm not getting any response, and the request times out:

The demo node does appear to receive the request correctly:

(When running in debug mode, putting a breakpoint on the entrance of _serve_request_vote, it appears to hang on the return statement)

The code implementing this request_vote functionality is as follows:

• Add srv_request_vote to be served in the background:

  # Create an RPC-server. (RequestVote)
  try:
      _logger.info("Request vote service is enabled")
      srv_request_vote = self._node.get_server(
          sirius_cyber_corp.RequestVote_1, "request_vote"
      )
      srv_request_vote.serve_in_background(self._serve_request_vote)
  except pycyphal.application.register.MissingRegisterError:
      _logger.info(
          "The request vote service is disabled by configuration (UAVCAN__SRV__REQUEST_VOTE__ID missing)"
      )

• The _serve_request_vote function itself:

  @staticmethod
  async def _serve_request_vote(
      # self,
      request: sirius_cyber_corp.RequestVote_1.Request,
      metadata: pycyphal.presentation.ServiceRequestMetadata,
  ) -> sirius_cyber_corp.RequestVote_1.Response:
      _logger.info(
          "\033[94m Request vote request %s from node %d \033[0m",
          request,
          metadata.client_node_id,
      )
  
      return sirius_cyber_corp.RequestVote_1.Response(
          term=1,
          vote_granted=True,
      )

This is pretty much the same way it is done in the demo example from pycyphal.

The only thing I'm unclear about is whether it might have something to do the way run() is implemented:

async def run(self) -> None:
    """
    The main method that runs the business logic. It is also possible to use the library in an IoC-style
    by using receive_in_background() for all subscriptions if desired.
    """
    _logger.info("Application Node started!")
    _logger.info("Running. Press Ctrl+C to stop.")

    while True:
        await asyncio.sleep(0.1)

In the demo example, there's more setup code here, however nothing related to the service (least_square in their case.)

I suspect maybe I need to use the library in "IoC-style by using receive_in_background()", however not sure how this looks in code, please bear with me and use simple words.

This is to be done after #3

For AppendEntries, what type to use for the entries variable?

From paper:

I'm thinking something like this:

# This service is used for the AppendEntries RPC

uint64 term
uint64 leaderID
uint64 prevLogIndex
uint64 prevLogTerm
LogEntry.1.0[<64] entries
uint64 leaderCommit

@sealed

---

uint64 term
bool success

@sealed

# This type is used to define a LogEntry for AppendEntries RPC
uint64 term
uint8[<=256] name
uint64 value
@sealed