mengw15 opened a new pull request, #7473:
URL: https://github.com/apache/texera/pull/7473
### What changes were proposed in this PR?
The backend of the per-user warehouse feature (umbrella #6870), all gated by
`warehouseEnabled` (default off — nothing changes for existing deployments):
- **Warehouse management API** — `WarehouseResource`: `GET
/warehouse/status` (always answers, so the frontend can hide the feature),
`POST /warehouse` and `DELETE /warehouse/{whid}` (403 while the flag is off).
Create validates the URI-safe name, mints the catalog name `user-<uid>-<name>`,
creates in Lakekeeper first and records the row after — a failed creation
leaves no orphaned state.
- **`LakekeeperClient`** — management-API create (Local flavor: storage
profile on the deployment's own object store, per-warehouse key prefix, STS
off) and **empty-first delete**: drop every table with `purgeRequested=true`,
then the namespaces, then the warehouse entity.
- **Per-execution injection** — `WorkflowExecuteRequest` gains `warehouseId:
Option[Int]`; `WorkflowService.resolveWarehouseName` checks ownership and
refuses an explicit pick while the feature is off (never a silent fallback —
#6930); the resolved name rides `WorkflowContext.warehouse` into every storage
URI (results, runtime statistics, console messages); the chosen `whid` is
recorded on `workflow_executions` (as `cuid` is today) so the picker can
preselect the workflow's last-used warehouse. `whid` is `ON DELETE SET NULL`:
deleting a warehouse purges its data, never the execution history.
- **Explicit read failure** — `WarehouseReadGuard`: paginating a
`/wh/<name>/…` result while the feature is off fails naming the warehouse,
instead of resolving against the shared warehouse and surfacing "table not
found" (#6930).
### Any related issues, documentation, discussions?
Closes #6932. Part of #6870 (design discussions #5293 and #6040). Builds on
#6944, #7359 and #7386.
### How was this PR tested?
Five specs, 30 cases green locally (`sbt "WorkflowExecutionService/testOnly
*LakekeeperClientSpec *WarehouseResourceSpec *WarehouseReadGuardSpec
*WorkflowServiceWarehouseSpec *ExecutionsMetadataPersistServiceSpec"`): the
Lakekeeper client runs against an in-process HTTP stub (create-payload shape;
the purge → namespace → warehouse delete order); the resource spec covers the
disabled gate and the create/list/delete flow on MockTexeraDB with a stubbed
client; resolution pins ownership and the no-silent-fallback rule; the read
guard pins the explicit failure message; the executions spec gains whid
recording and the SET-NULL-on-delete case. A delete-order assertion was
deliberately broken once to confirm it fails red.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (claude-fable-5)
--
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]
