developer/galaxy-game

Fork 0

Files

T

History

Ilia Denisov 7b43ce5844

Tests · Go / test (push) Successful in 1m56s

Details

Tests · Integration / integration (pull_request) Successful in 1m47s

Details

Tests · Go / test (pull_request) Successful in 2m2s

Details

Phase 28 (Step 1): backend support for race-name mail send

Phase 28's in-game mail UI groups personal threads by the other
party's race. To support that without an extra membership-listing
RPC, the diplomail subsystem now:

- accepts `recipient_race_name` on `POST /messages` and
  `POST /admin` (target=user) as an alternative to
  `recipient_user_id`; the service resolves it via the existing
  `Memberships.ListMembers(gameID, "active")` and rejects with
  `forbidden` when the matching member is no longer active;
- snapshots `diplomail_messages.sender_race_name` at send time for
  every player sender (admin / system rows stay NULL). The UI keys
  per-race threading on this column.

Schema, openapi, README, and a focused e2e test for the new path
(happy path + dual / missing / unknown / kicked errors) land in
this commit; the gateway + UI legs follow in subsequent commits on
this branch.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-15 22:07:48 +02:00

00001_init.sql

Phase 28 (Step 1): backend support for race-name mail send

2026-05-15 22:07:48 +02:00

embed.go

feat: backend service

2026-05-06 10:14:55 +03:00

README.md

docs: reorder & testing

2026-05-07 00:58:53 +03:00

README.md

Backend migrations

Goose migrations embedded into the backend binary by embed.go. Applied at startup before any listener opens (see internal/postgres).

Pre-production single-file rule

While the platform is not yet in production, every schema change goes into the existing 00001_init.sql file rather than a new 00002_*-prefixed file. The intent is to keep the schema in one canonical place so reviewers and developers do not have to reconstruct the latest shape from a chain of incremental migrations.

Operationally this means that pulling a branch with schema changes requires a fresh database — the only consumer today is local development and integration tests, both of which spin up disposable Postgres instances.

Remove this rule before the first production deployment. From that point on every schema change must be a new migration file with a monotonically increasing prefix, and 00001_init.sql becomes immutable history.

If you need to make a change, edit 00001_init.sql directly. Down migrations should still be kept in sync (they live at the bottom of the file — currently a single DROP SCHEMA backend CASCADE).