Handle Init Message and Store Cluster Metadata - The Messenger

                      TASK
                    

Implementation

Before processing any workload, Maelstrom sends an init message to each node. This message tells your node its identity and the full cluster membership.

The init message looks like:

{
  "type": "init",
  "msg_id": 1,
  "node_id": "n1",
  "node_ids": ["n1", "n2", "n3"]
}

Your task is to handle the init message by storing the node_id (your identity) and node_ids (all cluster members). Then respond with an init_ok message:

{
  "type": "init_ok",
  "in_reply_to": 1
}

The in_reply_to field must match the msg_id from the init request.

Sample Test Cases

Respond to initTimeout: 5000ms

Input

{
  "src": "c0",
  "dest": "n1",
  "body": {
    "type": "init",
    "msg_id": 1,
    "node_id": "n1",
    "node_ids": [
      "n1"
    ]
  }
}

Expected Output

{"src": "n1", "dest": "c0", "body": {"type": "init_ok", "in_reply_to": 1, "msg_id": 0}}

Hints

Hint 1▾

The init message contains node_id and node_ids fields

Hint 2▾

Store these values for use in subsequent message handling

Hint 3▾

Reply with init_ok message type

Resources

Maelstrom Initialization

Details on the init message and expected response

                      OVERVIEW
                    

Theoretical Hub

Node Initialization

Every distributed system needs a bootstrap phase where nodes learn about themselves and their peers. The init message serves this purpose in Maelstrom.

Understanding Identity

The node_id field gives your node its unique identity. This is critical because:

All messages you send must use this as the src field
Other nodes will address messages to you using this ID
Your identity distinguishes you from other nodes in the cluster

Cluster Topology

The node_ids array tells you about all nodes in the cluster. This information becomes essential for:

Broadcast algorithms - knowing who to send messages to
Consensus protocols - calculating quorums
Leader election - participating in voting

Request-Response Pattern

The in_reply_to field establishes a correlation between requests and responses. This pattern is fundamental in distributed systems where you need to match responses to outstanding requests.

Request:  { "type": "init", "msg_id": 1, ... }
Response: { "type": "init_ok", "in_reply_to": 1 }

This correlation allows the sender to:

Track which requests have been answered
Implement timeouts for unresponsive nodes
Handle out-of-order message delivery

Key Concepts

initializationnode identitycluster topology

main.py

python

#!/usr/bin/env python3
import sys
import json
class Node:
    def __init__(self):
        self.node_id = None
        self.node_ids = []
        self.next_msg_id = 0
    
    def send(self, dest, body):
        # TODO: Implement message sending
        pass
    
    def reply(self, request, body):
        # TODO: Implement reply with in_reply_to
        pass
def main():
    node = Node()
    
    for line in sys.stdin:
        message = json.loads(line)
        body = message["body"]
        msg_type = body["type"]
        
        if msg_type == "init":
            # TODO: Handle init message
            # 1. Store node_id and node_ids
            # 2. Reply with init_ok
            pass
if __name__ == "__main__":
    main()