Yicong-Huang opened a new issue, #7064:
URL: https://github.com/apache/texera/issues/7064
### 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?
```sh
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:
```sh
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
```shell
✓ 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
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
