The GitHub Actions job "Required Checks" on texera.git/xinyuan-loop-feb has succeeded. Run started by GitHub user aglinxinyuan (triggered by aglinxinyuan).
Head commit for run: 36c4ff4501eb051bb882503d9a9e958f6f69d7b1 / Xinyuan Lin <[email protected]> fix(loop): keep UI and engine in sync on the loop-MATERIALIZED rule PR #4206 review feedback: the previous behavior silently rewrote WorkflowExecutionService's executionMode to MATERIALIZED when the workflow contained a Loop Start, but the frontend Settings panel kept displaying whatever the user picked (often PIPELINED), so the UI and the engine ran on different settings with no signal to the user. Frontend (settings.component): * On every workflowChanged event, walk the operators and check for LoopStart / LoopEnd. * If present, force executionMode to MATERIALIZED via WorkflowActionService.updateExecutionMode, disable the radio group so the user can't toggle it back, and show a single info toast the first time we flip the selection (subsequent passes don't re-notify). * If absent, re-enable the radio group. * Add a styled hint under the radio group explaining the lock. * Tests: six new cases covering coerce-on-LoopStart, coerce-on- LoopEnd, re-enable on loop removal, one-shot toast, no toast when the workflow already opens with MATERIALIZED, and no-op behavior when no loop is present. Backend (WorkflowExecutionService.scala): * Restore the silent executionMode=MATERIALIZED coercion as a safety net for non-frontend callers (direct API submissions, older clients). With the frontend now mirroring this rule, the coercion is normally a no-op; if it does fire, both sides end up at MATERIALIZED, not divergent. Report URL: https://github.com/apache/texera/actions/runs/26309783318 With regards, GitHub Actions via GitBox
