Skip to content

Centralize room, RaceSession, attempt, and solve persistence #204

Description

@coder13

Part of #199.

Goal

Stop Socket.IO handlers and Mongoose document methods from directly owning room/session/result persistence behavior. Put the aggregate behind a single tested service/repository boundary that can use PostgreSQL authoritatively.

Scope

Create explicit operations for at least:

  • create room and initial race session;
  • load room and active/selected session;
  • join, leave, ban, and unban;
  • assign owner/admin and session control roles;
  • create, start, pause, end, and switch race sessions;
  • create the next attempt;
  • submit and edit an idempotent solve;
  • hide, archive, or delete a room according to the retention contract.

Socket handlers should authorize and translate protocol messages, then call these operations. They should not directly mutate embedded attempts, result maps, or room event state.

Requirements

  • Preserve the current Socket.IO protocol during the first phase where practical.
  • Preserve idempotent submission IDs and immutable attempt keys.
  • Use PostgreSQL transactions wherever one user action changes room, session, attempt, participant, and solve state together.
  • Keep authorization inside or immediately adjacent to the domain operation so alternate callers cannot bypass it.
  • Define repository implementations or feature flags needed for migration comparison and rollback.
  • Emit realtime events only after durable writes succeed.
  • Keep chat transport outside this persistence scope unless required by the contract.

Acceptance criteria

  • All room/session/attempt/solve mutations have explicit service operations.
  • Socket handlers no longer directly mutate the persisted aggregate.
  • Result submission remains idempotent across reconnects and retries.
  • Event changes end/create sessions without deleting history.
  • Transactions prevent partially-created sessions, attempts, or solves.
  • Authorization tests cover owner, admin, participant, banned, anonymous, and stale-session cases.
  • Existing normal-room client behavior and protocol tests continue passing.
  • The persistence boundary supports shadow comparison and an authoritative PostgreSQL mode.

Dependencies

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: dataMongoDB, PostgreSQL, migrations, backfills, and data integrityarea: platformBuild, CI, deployment, operations, and repository infrastructurearea: resultsSolves, scrambles, history, statistics, and exportsenhancementNew feature or requestpriority: P1High-priority work for the next delivery cycle

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions