mengw15 opened a new issue, #8593: URL: https://github.com/apache/texera/issues/8593
Three components decide whether a run is missing a warehouse, and none of them shares the answer: - `ComputingUnitSelectionComponent.warehouseRequiredButMissing` — `warehouseEnabled` from the `GET /warehouse/status` response (falling back to the boot-time config when that request fails, so a transport error cannot un-gate a run), and the pick from `WarehouseService`. This one also decides whether the picker renders at all. - `ExecuteWorkflowService` — the boot-time `config.env.warehouseEnabled` and the same pick. This is the one that actually refuses the run. - `WorkflowFormComponent.hasNoWarehouse` (#8592) — the same pair as the service, so the form view's button predicts the refusal exactly. They agree today only because `status.enabled` and `config.env.warehouseEnabled` both come from `StorageConfig.warehouseEnabled` server-side. Raised as a P3 during the picker's review (#8551): if `status.enabled` ever becomes dynamic or per-user, a run could be refused by the service while the picker stays hidden, or offered by a button the service then rejects. The fix is one owner — `WarehouseService` exposing the predicate, with the status response and the boot config reconciled in one place — and three readers. Deliberately not done inside #8592, which is an eight-line fix, or #8590, which is already rewriting the picker. Not urgent: the three agree today, and a divergence would at worst cost an extra toast or a hidden picker — the backend (#7751) is the authority on whether a run is allowed. This is the cleanup to do **before** `status.enabled` becomes dynamic or per-user, not before that. Part of #6870. -- 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]
