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

Labels

No labels
No labels

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions