refactor(game): lock-free storage, remove /command, flatten engine wrapper
Three-stage refactor of the game-engine plumbing (game logic untouched): Stage 1 — lock-free persistence + admin serialisation. Remove the file lock from repo/fs (the .lock file, the Read/Write-vs-*Safe duality and the dead ReadSafe polling) and replace the two-step rename with a single atomic rename so concurrent reads are torn-free without a lock. Serialise the state-mutating admin writers (init/turn/banish) with one shared router LimitMiddleware, rewritten to block on the request context instead of a racy shared 100ms timer. Stage 2 — remove the obsolete immediate-command path end to end. Players submit through PUT /api/v1/order; the legacy PUT /api/v1/command path is deleted across game (route, handler, 24 command factories, Ctrl), backend (Commands handler/route, engineclient.ExecuteCommands), gateway (dispatch + executeUserGamesCommand + routing entry), the FlatBuffers/model contract (UserGamesCommand[Response]) and transcoder, plus every affected OpenAPI/README/FUNCTIONAL/ARCHITECTURE doc. The integration proxy test is converted to the order path. Stage 3 — flatten the REST->engine wrapper. Replace the executor adapter, the controller package functions and RepoController with one concrete controller.Service; drop the single-implementation Repo and Storage interfaces (repo.Repo / fs.FS are now concrete). Handlers depend on a thin handler.Engine seam and own the domain->REST projection; storage is resolved once at startup instead of per request. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -201,31 +201,15 @@ table CommandItem {
|
||||
cmd_error_message: string;
|
||||
}
|
||||
|
||||
// UserGamesCommand is the signed-gRPC request payload for
|
||||
// `MessageTypeUserGamesCommand`. game_id selects the target running
|
||||
// game; gateway re-encodes commands into the engine JSON shape and
|
||||
// forwards through `POST /api/v1/user/games/{game_id}/commands`.
|
||||
table UserGamesCommand {
|
||||
game_id: common.UUID (required);
|
||||
commands: [CommandItem];
|
||||
}
|
||||
|
||||
// UserGamesOrder is the signed-gRPC request payload for
|
||||
// `MessageTypeUserGamesOrder`. Identical to UserGamesCommand but
|
||||
// carries `updated_at` so the order-validate path can reject stale
|
||||
// submissions.
|
||||
// `MessageTypeUserGamesOrder`. game_id selects the target running game;
|
||||
// `updated_at` lets the order-validate path reject stale submissions.
|
||||
table UserGamesOrder {
|
||||
game_id: common.UUID (required);
|
||||
updated_at: int64;
|
||||
commands: [CommandItem];
|
||||
}
|
||||
|
||||
// UserGamesCommandResponse is the success acknowledgement returned
|
||||
// for `MessageTypeUserGamesCommand`. The engine answers with
|
||||
// `204 No Content` on success, so the FB shape is intentionally empty
|
||||
// — kept as a typed envelope for future extension.
|
||||
table UserGamesCommandResponse {}
|
||||
|
||||
// UserGamesOrderResponse mirrors the engine's `PUT /api/v1/order`
|
||||
// success body: it echoes the stored order back to the caller with
|
||||
// the engine-assigned `updated_at` timestamp and per-command
|
||||
|
||||
Reference in New Issue
Block a user