State Machine

This project implements a state machine for tracking character quest progression via a REST API. It includes a server to manage the state machine and a client to send test events.

Directory Structure

• /Server: Contains the server-side application, state machine logic, and data definitions (events, states, transitions).
• /Client: Contains a client application to send pre-defined events to the server.

Build and Run Instructions

Server

1. Navigate to the server directory:

   cd Server

2. Build the server executable:

   go build -o state_machine *.go

   (This command assumes all necessary .go files for the server are in the Server directory or its subdirectories if you adjust the *.go pattern or use module-aware mode builds).
3. Run the server:

   ./state_machine

   The server will start on http://localhost:8080.

Client

1. Ensure the server is running.
2. Navigate to the client directory:

   cd Client

3. Run the client:

   go run main.go

   The client will load events from Client/Input/input_events.json, adjust their timestamps to be in the future, and send them to the server.

Assumptions Made by the State Machine & System

1. Asynchronous Event Processing:

   • When an event is received via the /quest-event API, it is validated and scheduled for future processing based on its timestamp. The API call returns an immediate response (e.g., "accepted" or an error) and does not wait for the event's scheduled time to execute.
   • If an event is rejected during initial validation (e.g., timestamp in the past, unknown event type), an error status is returned immediately.
   • If a scheduled event is later found to be invalid at its processing time (e.g., if character deletion were implemented and the character no longer exists, or no valid transition exists), it is silently ignored (a log message is generated on the server, but no direct response is sent back to the original API caller for that past request).

2. Data Configuration:

   • The server relies on events.json, states.json, and state_machine.json files located in a Server/Data/ subdirectory. These files must be correctly formatted and present at startup.
   • A state named "NotStarted" must be defined in states.json as it's the default initial state for characters.

3. Quest and Character Handling:

   • For a begin_quest event, the QuestID for the character's new quest is currently derived from the QuestID of the incoming request.
   • For events other than begin_quest, the QuestID in the request must match the character's currently active QuestID as long as the character has an active quest.

4. Timestamps:

   • Incoming event timestamps in QuestEventRequest are expected to be in RFC3339 format.
   • Events are only scheduled if their timestamp is strictly in the future relative to the server's current time when the request is received.

5. State Machine Definitions:

   • Self-transitions (a state transitioning to itself on an event) are disallowed by the current design in createStateMachine.
   • Conflicting transitions (defining multiple different target states for the same from_state and event combination) are disallowed.

6. Client Behavior:

   • The provided client (Client/main.go) loads events from Client/Input/input_events.json.
   • The client actively adjusts the timestamps of these loaded events to be in the near future before sending them to ensure they are accepted by the server's "timestamp in the future" validation.