The API boots on its database, in dev and in CI #368

Closed
opened 2026-10-11 16:26:02 +00:00 by root · 8 comments
root commented 2026-10-11 16:26:02 +00:00 (Migrated from gitlab.core-project.space)

Imported from GitHub amaurycoudr/chess-project#368, opened by @amaurycoudr on 2026-10-11 16:26 UTC.


Parent

#354

What to build

Stories 19, 20, 21 and 22 of #354. The API config gains a required database URL; a missing one throws at startup, as a missing port does. The boot entry point connects, checks the database answers, and only then listens. When the database does not answer, it refuses to start with a message naming the setting. A stopped server closes the pool. The app module receives the database handle as an option and provides it under a token, as it does the allowed origins; the room module does not use it yet. The in-process app fixture for the wire tests passes an in-process database, so the existing wire tests keep their one-line setup.

Add the migrate entry point as a second root entry beside the boot one. It migrates and exits, and never runs inside the server: the production server never migrates on boot (ADR 0032).

Locally, a dev Compose project runs one shared Postgres for the machine with one database per worktree. The worktree env sync writes the worktree's database URL into the API's local env file next to its port. A db script starts the container and creates the worktree's database when it is missing. When the database does not answer, the migrate step names that script. The API's dev script and the browser suite's API command run the migrate entry point before the server. drizzle-kit studio stays available locally.

In CI, the browser-suite job runs a Postgres service container, and the slow test task passes the database URL through to the built API.

Propose in the PR body (do not edit): the API's coding standards should mention the database module in the layout and the in-process database in the wire-test fixture sentence. See #354, API wiring and Local dev, tests and CI.

Seam: loadConfig unit tests; the API's database module; the existing browser suite, unchanged, run locally and in CI against a real migrated Postgres.

Acceptance criteria

  • loadConfig throws when the database URL is missing and parses it when present.
  • The API refuses to start when its database does not answer, naming the setting, and never starts listening.
  • The existing wire tests pass on an in-process database with no change to their setup.
  • Two worktrees running pnpm dev side by side use different databases on the one shared container.
  • Running the migrate step against a missing local database names the db script.
  • The local browser suite and CI's browser suite run green against a real, migrated Postgres.
  • The PR body proposes the API coding-standards wording.
  • The gate is green.
> _Imported from GitHub [amaurycoudr/chess-project#368](https://github.com/amaurycoudr/chess-project/issues/368), opened by [@amaurycoudr](https://github.com/amaurycoudr) on 2026-10-11 16:26 UTC._ <!-- github-issue:368 --> --- ## Parent #354 ## What to build Stories 19, 20, 21 and 22 of #354. The API config gains a required database URL; a missing one throws at startup, as a missing port does. The boot entry point connects, checks the database answers, and only then listens. When the database does not answer, it refuses to start with a message naming the setting. A stopped server closes the pool. The app module receives the database handle as an option and provides it under a token, as it does the allowed origins; the room module does not use it yet. The in-process app fixture for the wire tests passes an in-process database, so the existing wire tests keep their one-line setup. Add the migrate entry point as a second root entry beside the boot one. It migrates and exits, and never runs inside the server: the production server never migrates on boot (ADR 0032). Locally, a dev Compose project runs one shared Postgres for the machine with one database per worktree. The worktree env sync writes the worktree's database URL into the API's local env file next to its port. A `db` script starts the container and creates the worktree's database when it is missing. When the database does not answer, the migrate step names that script. The API's dev script and the browser suite's API command run the migrate entry point before the server. `drizzle-kit studio` stays available locally. In CI, the browser-suite job runs a Postgres service container, and the slow test task passes the database URL through to the built API. Propose in the PR body (do not edit): the API's coding standards should mention the database module in the layout and the in-process database in the wire-test fixture sentence. See #354, *API wiring* and *Local dev, tests and CI*. Seam: `loadConfig` unit tests; the API's database module; the existing browser suite, unchanged, run locally and in CI against a real migrated Postgres. ## Acceptance criteria - [ ] `loadConfig` throws when the database URL is missing and parses it when present. - [ ] The API refuses to start when its database does not answer, naming the setting, and never starts listening. - [ ] The existing wire tests pass on an in-process database with no change to their setup. - [ ] Two worktrees running `pnpm dev` side by side use different databases on the one shared container. - [ ] Running the migrate step against a missing local database names the `db` script. - [ ] The local browser suite and CI's browser suite run green against a real, migrated Postgres. - [ ] The PR body proposes the API coding-standards wording. - [ ] The gate is green.
root commented 2026-10-11 16:26:02 +00:00 (Migrated from gitlab.core-project.space)

GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links).

  • Parent (sub-issue of): #354
  • Blocked by: #367
  • Blocking: #369
> _GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links)._ <!-- github-relations --> - Parent (sub-issue of): #354 - Blocked by: #367 - Blocking: #369
root commented 2026-10-13 08:39:43 +00:00 (Migrated from gitlab.core-project.space)

mentioned in issue #369

mentioned in issue #369
root commented 2026-10-13 08:41:20 +00:00 (Migrated from gitlab.core-project.space)

mentioned in issue #354

mentioned in issue #354
root commented 2026-10-13 08:41:23 +00:00 (Migrated from gitlab.core-project.space)

mentioned in issue #367

mentioned in issue #367
root commented 2026-10-13 08:42:25 +00:00 (Migrated from gitlab.core-project.space)

marked this issue as related to #354

marked this issue as related to #354
root commented 2026-10-13 08:42:32 +00:00 (Migrated from gitlab.core-project.space)

marked this issue as related to #367

marked this issue as related to #367
root commented 2026-10-13 08:42:33 +00:00 (Migrated from gitlab.core-project.space)

marked this issue as related to #369

marked this issue as related to #369
root commented 2026-10-13 10:17:36 +00:00 (Migrated from gitlab.core-project.space)

mentioned in merge request !506

mentioned in merge request !506
root (Migrated from gitlab.core-project.space) closed this issue 2026-10-13 14:10:08 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
amaurycoudr/chess-project#368
No description provided.