refactor(game): lock-free storage, remove /command, flatten engine wrapper
Tests · Go / test (push) Successful in 2m27s
Tests · UI / test (push) Waiting to run
Tests · Integration / integration (pull_request) Successful in 1m45s
Tests · Go / test (pull_request) Successful in 3m13s
Tests · UI / test (pull_request) Successful in 3m8s

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:
Ilia Denisov
2026-05-30 13:37:07 +02:00
parent e36d33482f
commit 601970b028
65 changed files with 681 additions and 2804 deletions
+2 -18
View File
@@ -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