The GitHub Actions job "Required Checks" on texera.git/main has failed. Run started by GitHub user github-merge-queue[bot] (triggered by github-merge-queue[bot]).
Head commit for run: 052cf38c02797d8c10afceea2c39f11d3d16dfdd / Yicong Huang <[email protected]> fix(local-dev): don't abort `up` on an already-applied sql/updates changeSet (#7076) ### What changes were proposed in this PR? `bin/local-dev.sh up` against a fresh docker volume never reached the sbt build: it died on the last `sql/updates` changeSet. Postgres applies `sql/texera_ddl.sql` itself — compose mounts `sql/` into `/docker-entrypoint-initdb.d` — and that DDL is kept in sync with `sql/updates/*`, so the changeSets local-dev replays immediately afterwards re-create objects that are already there. 23–27 are incidentally idempotent and pass; `28.sql`'s `dataset_owner_uid_name_key` is not, and `sql/texera_ddl.sql`'s `UNIQUE (owner_uid, name)` on `dataset` already created it under exactly that auto-generated name. `infra_ensure_db_schema` picks seed-vs-replay by probing for the `feedback` table. On a fresh volume the entrypoint has just created it, so the replay path is taken — and the `seed` branch written for this very case (record every changeSet as applied without executing it) is unreachable, because the entrypoint always wins the race. ``` Before: fresh volume -> entrypoint applies full DDL -> replay 23-28 -> 28 fails -> no build After: fresh volume -> entrypoint applies full DDL -> 28 recorded as applied -> build runs ``` The fix is in the replay loop rather than the probe: a psql failure whose every `ERROR:` line is `already exists` means the changeSet's effect is already in the schema, so record it and carry on. That covers the next `sql/updates/N.sql` that isn't accidentally idempotent too, instead of fixing only `28.sql`. `_sql_errors_all_already_exist` is deliberately narrow — a `duplicate key` is a data conflict rather than an applied schema change, and a failure with no `ERROR:` line at all is never assumed harmless — so an incomplete schema still stops the build instead of reaching jOOQ codegen with tables that aren't there. While in the same lines: psql's stderr is kept instead of redirected to `/dev/null`. It holds the one line that explains the abort, and the old code discarded it and then told the operator to re-run the file by hand to find out why. ### Any related issues, documentation, discussions? Closes #7064 ### How was this PR tested? Unit coverage for the detector in both directions, plus two structural guards on the wiring, in the existing `infra`-job suite: ``` $ bash bin/local-dev/tests/test_local_dev_sh.sh ... ✓ already-applied detector: relation already exists (the #7064 failure) ✓ already-applied detector: several already-exists errors, nothing else ✓ already-applied detector: already-exists around harmless NOTICE/ROLLBACK chatter ✓ already-applied detector: non-ASCII identifier already exists ✓ already-applied detector: syntax error ✓ already-applied detector: missing relation ✓ already-applied detector: one already-exists mixed with one real error ✓ already-applied detector: duplicate key is a data conflict, not an applied change ✓ already-applied detector: empty stderr ✓ already-applied detector: no ERROR line at all ✓ already-applied detector: missing stderr file ✓ already-applied detector: no argument ✓ infra_apply_sql_updates consults the already-applied detector ✓ infra_apply_sql_updates keeps psql stderr for diagnosis 64 passed, 0 failed ``` The pytest half of the same job reports `1 failed, 42 passed` on this branch. That failure is `test_is_dirty_after_seed_then_edit`, which is unrelated to this change — it reproduces identically on a pristine `main` checkout, and this PR touches neither `tui.py` nor that test. It is #7075, fixed separately. End-to-end on the real stack (Ubuntu 24.04.4, docker 29.1.3), reproducing the failure and then confirming the fix: ```sh bin/local-dev.sh down docker volume rm texera-local-dev_postgres_data bin/local-dev.sh up ``` Before: ``` → 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 ``` After: ``` → postgres: applying sql/updates/27.sql (changeSet 27) → postgres: applying sql/updates/28.sql (changeSet 28) ○ postgres: sql/updates/28.sql already in schema (recording changeSet 28) ✓ postgres: 6 sql/update(s) applied ... ✓ 14 of 14 services healthy ``` The changeSet is recorded, so it is not retried on the next run: ``` $ docker exec texera-postgres psql -U texera -d texera_db -tAc \ "SELECT id||':'||exectype FROM public.databasechangelog ORDER BY orderexecuted" 23:EXECUTED 24:EXECUTED 25:EXECUTED 26:EXECUTED 27:EXECUTED 28:EXECUTED ``` ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5) --------- Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]> Co-authored-by: Xinyuan Lin <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/31672096026 With regards, GitHub Actions via GitBox
