mengw15 opened a new pull request, #7752: URL: https://github.com/apache/texera/pull/7752
> **Stacked PR** — based on #7536 (`feat/6933-warehouse-frontend`), not on `main`. That branch adds the warehouse picker this change reads from, so the diff and file list here include its commits; only the top commit belongs to this PR. Please review/merge #7536 first — this is a draft until it lands, after which the diff collapses to just the change described below. ### What changes were proposed in this PR? With per-user warehouses enabled, an execution carrying no `warehouseId` silently wrote into the shared default warehouse: `WorkflowService.resolveWarehouseName` mapped `None` to `None` whenever the flag was on. So "a run writes into the user's own warehouse" was a UI convention rather than a system property — and one path already violated it: `SyncExecutionResource` hardcoded `warehouseId = None`, so on a deployment with the feature on, **every agent-driven execution landed in the shared warehouse**. The fix makes the pick required the same way a **computing unit** already is, and carries it along the same path the computing unit already travels: - **`WorkflowService.resolveWarehouseName` rejects instead of falling back**: with the flag on and nothing picked, the execution fails rather than being routed into shared storage. The websocket path needs nothing more — the UI always sends its pick. - **`SyncExecutionRequest` gains `warehouseId`** and the endpoint forwards it instead of hardcoding `None`. - **`agent-service` threads `warehouseId` through** `ExecutionConfig` and the delegate config into that request body, mirroring `computingUnitId` line for line. - **The frontend sends the warehouse the user picked** when creating an agent, right where it already sends the selected computing unit (`agent.service.ts`). This is not a privilege change: an explicit `whid` was, and still is, checked against the caller's `uid`. Flag-off behaviour is unchanged — an explicit pick is still refused loudly (#6930), and no pick still means the shared warehouse. Worth settling while the flag is off everywhere: tightening this later, once a deployment runs with the lenient fallback, would break callers that work today. ### Any related issues, documentation, discussions? Closes #7751. Part of #6870, follow-up to #6932. Stacked on #7536 (warehouse picker). ### How was this PR tested? - **Backend**: `WorkflowServiceWarehouseSpec`'s contract case flips from "no pick keeps the shared warehouse" to "no pick is refused while enabled", with the flag-off fallback kept as its own case. `WorkflowServiceWarehouseSpec` + `SyncExecutionResourceSpec` run locally: **38/38 passed**; `WorkflowExecutionService/scalafmtCheck` (main + Test) passes. - **agent-service**: `tsc --noEmit` passes and `bun test workflow-execution-tools.spec.ts` is **23 pass / 0 fail**. - **Frontend**: `agent.service.spec.ts` gains a `WarehouseService` stub mirroring the existing computing-unit stub, asserting the payload carries the selected `warehouseId` and omits it when nothing is selected; `ng test --include=...` passes. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-opus-4-8) -- 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]
