Skip to content

Fresh local-dev postgres volume fails on sql/updates/28.sql before the build starts #7064

Description

@Yicong-Huang

What happened?

bin/local-dev.sh up against a fresh docker volume always aborts before
the sbt build, on the last sql/updates changeSet.

Root cause: two bootstrappers write the same schema, and the seed-vs-replay
probe can't tell them apart.

bin/single-node/docker-compose.yml mounts ../../sql -> /docker-entrypoint-initdb.d
  postgres first-init runs texera_ddl.sql, which is kept in sync with
  sql/updates/* and therefore already contains every changeSet
        |
        v
infra_ensure_db_schema() picks seed-vs-replay by probing for the `feedback`
table.  It exists -- the entrypoint just created it -- so the REPLAY path
re-runs changeSets 23-28 against a DB that already has all of them.
  23-27 happen to be idempotent  -> pass
  28 is not                      -> ERROR, up() returns non-zero

sql/updates/28.sql adds dataset_owner_uid_name_key, which
sql/texera_ddl.sql:291 (UNIQUE (owner_uid, name)) already created under
that auto-generated name.

The seed branch of infra_apply_sql_updates — record every changeSet as
applied without executing it — exists for exactly this fresh-DB case, but is
unreachable, because the container entrypoint always wins the race.

Before:  fresh volume -> entrypoint applies full DDL -> local-dev replays 23-28 -> 28 fails -> no build
After:   fresh volume -> entrypoint applies full DDL -> local-dev seeds 23-28 as applied -> build runs

The failure isn't specific to 28.sql; it will recur on the next
sql/updates/N.sql that isn't accidentally idempotent.

How to reproduce?

bin/local-dev.sh down
docker volume rm texera-local-dev_postgres_data
bin/local-dev.sh up

Workaround — record the changeSet as applied by hand, since the constraint
really is present:

docker exec texera-postgres psql -U texera -d texera_db -qc "
  INSERT INTO public.databasechangelog
    (id, author, filename, dateexecuted, orderexecuted, exectype)
  VALUES ('28','kunwp1','changelog.xml', now(),
    (SELECT COALESCE(MAX(orderexecuted),0)+1 FROM public.databasechangelog),
    'EXECUTED')"

Version/Branch

1.3.0-incubating-SNAPSHOT (main)

Relevant log output

  ✓  infra: 5 containers up
  →  postgres: applying sql/updates/23.sql (changeSet 23)
  →  postgres: applying sql/updates/24.sql (changeSet 24)
  →  postgres: applying sql/updates/25.sql (changeSet 25)
  →  postgres: applying sql/updates/26.sql (changeSet 26)
  →  postgres: applying sql/updates/27.sql (changeSet 27)
  →  postgres: applying sql/updates/28.sql (changeSet 28)
  ✗  postgres: sql/updates/28.sql failed -- inspect with: docker exec -i texera-postgres psql -U texera -d texera_db < sql/updates/28.sql

$ docker exec -i texera-postgres psql -U texera -d texera_db < sql/updates/28.sql
SET
BEGIN
DO
ERROR:  relation "dataset_owner_uid_name_key" already exists
ROLLBACK

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions