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
What happened?
bin/local-dev.sh upagainst a fresh docker volume always aborts beforethe sbt build, on the last
sql/updateschangeSet.Root cause: two bootstrappers write the same schema, and the seed-vs-replay
probe can't tell them apart.
sql/updates/28.sqladdsdataset_owner_uid_name_key, whichsql/texera_ddl.sql:291(UNIQUE (owner_uid, name)) already created underthat auto-generated name.
The
seedbranch ofinfra_apply_sql_updates— record every changeSet asapplied without executing it — exists for exactly this fresh-DB case, but is
unreachable, because the container entrypoint always wins the race.
The failure isn't specific to
28.sql; it will recur on the nextsql/updates/N.sqlthat isn't accidentally idempotent.How to reproduce?
Workaround — record the changeSet as applied by hand, since the constraint
really is present:
Version/Branch
1.3.0-incubating-SNAPSHOT (main)
Relevant log output