The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-7740-8be174308d4e597f120253cc68dbd4f21c0af1ed has failed. Run started by GitHub user kunwp1 (triggered by kunwp1).
Head commit for run: 51f38e13d66e42070872ccb532b7796b82273be4 / Meng Wang <[email protected]> feat(storage): give the default Iceberg warehouse its own key prefix (#7740) ### What changes were proposed in this PR? The deployment scripts created the default Lakekeeper warehouse without a `key-prefix`, so it claimed the entire bucket. Per-user warehouses (#6870) live in the same bucket under `user-<uid>-<name>`, which Lakekeeper rejects as an overlapping storage profile — making per-user warehouse creation fail on every standard deployment. The default warehouse now owns an explicit prefix (`shared`), so it and the per-user warehouses are siblings. `WarehouseResource` is unchanged — the mismatch was entirely in deployment configuration. The same prefix goes into the CI warehouse (`build.yml`), so the integration environment matches a real deployment — that is where a future integration test of the warehouse management API would otherwise hit the same overlap. It is a literal there rather than extracted from `storage.conf` like the neighbouring values: the prefix describes how the deployment lays out the bucket and no runtime code reads it, and every key currently in `storage.conf` is read by `StorageConfig`. Both compose payloads carry the prefix, not just the create one: Lakekeeper rejects a storage update whose `key_prefix` differs from the stored value, and an omitted field counts as a change, so the start-up endpoint refresh (#6195) would fail with HTTP 400 against a prefixed warehouse. ### Any related issues, documentation, discussions? Closes #7739. Existing deployments must drop and recreate the default warehouse: Lakekeeper refuses to change `key_prefix` in place. The cost is bounded — `ComputingUnitMaster.recurringCheckExpiredResults` purges results, runtime statistics and logs past `result-cleanup.ttl-in-seconds` (default 86400) — and Texera addresses the warehouse by name, so nothing else changes. ### How was this PR tested? Rendered both compose payloads with the real `.env` values and confirmed each is valid JSON carrying `key-prefix`; `docker compose config` passes. Against a live Lakekeeper: the refresh payload without the prefix returns HTTP 400 (`Field key_prefix cannot be updated`) and with it returns 200; a per-user warehouse creates successfully alongside a prefixed default (HTTP 201), and an execution targeting it writes results, runtime statistics and console messages entirely under that warehouse's prefix while the shared prefix stays empty. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-opus-5) Report URL: https://github.com/apache/texera/actions/runs/32222114358 With regards, GitHub Actions via GitBox
