Skip to content

fix(docker): distinguish skipped vs completed migrations in entrypoint log - #2

Draft
dnplkndll wants to merge 1 commit into
mainfrom
fix/docker-entrypoint-migration-log
Draft

fix(docker): distinguish skipped vs completed migrations in entrypoint log#2
dnplkndll wants to merge 1 commit into
mainfrom
fix/docker-entrypoint-migration-log

Conversation

@dnplkndll

@dnplkndll dnplkndll commented Jul 26, 2026

Copy link
Copy Markdown

PRACTICE PR on fork — for quality review before filing upstream. Do not merge.

Title: fix(docker): distinguish skipped vs completed migrations in entrypoint log

Related to #TBD (upstream issue to be filed on approval; companion to the helm init fix).

Problem

entrypoint.sh prints Successfully migrated DB! unconditionally — including
when it skipped database:init:prod because the core schema already
existed. When something pre-creates that schema on an otherwise-empty database
(as the helm chart's init container did until the companion PR), the log claims
success while the server boots against an unmigrated database and every
workspace query fails with relation "core.user" does not exist. The log line
actively points operators away from the real cause.

Change

Track whether init ran and log the two paths distinctly:

  • fresh path → Database initialized and migrated.
  • skip path → Base schema already present - skipping database init (running delta upgrades only).Delta upgrades applied (base schema was already present).

No behavior change — logging only.

Verification

Docker compose boot transcripts: fresh volume shows the init path; restart
shows the skip path. [transcripts]

Logic verification (stubbed harness, both paths)

has_schema=f -> "Database appears to be empty, running migrations." / "Database initialized and migrated."
has_schema=t -> "Base schema already present - skipping database init (running delta upgrades only)." / "Delta upgrades applied (base schema was already present)."

…t log

The entrypoint printed "Successfully migrated DB!" unconditionally — even
when it skipped database:init:prod because the "core" schema already
existed. When init is skipped on a database that is actually empty (e.g.
something pre-created the schema), the log claims success while the server
boots against an unmigrated database, which makes the failure very hard to
diagnose. Log the two paths distinctly instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant