aglinxinyuan opened a new pull request, #7154: URL: https://github.com/apache/texera/pull/7154
### What changes were proposed in this PR? A Loop Start whose single input port is fed by **two** upstream operators is accepted by the GUI, then rejected at `StartWorkflow`: ``` requirement failed: Loop Start input port ... expected exactly one reader URI, got 2 ``` Nothing in the editor hints the plan is invalid until the run fails ([discussion #6966](https://github.com/apache/texera/discussions/6966)). The restriction itself is intended — fan-in belongs in a `Union` before the loop — but it should be visible while building the workflow. `InputPort` already has a `disallowMultiLinks` flag, and the frontend honors it in two places: | Guard | Where | Source of the flag | |---|---|---| | Editor refuses to draw a second link into the port | `workflow-editor.component.ts` | operator metadata (`additionalMetadata.inputPorts[i].disallowMultiLinks`) | | Workflow validation requires exactly one input | `validation-workflow.service.ts` | the operator predicate, via `WorkflowUtilService.inputPortToPortDescription` mapping `disallowMultiLinks` → `disallowMultiInputs` | The loop operators simply never set it. This PR sets it on the shared `LoopOpDesc` input port — **one line**, no frontend change. It applies to **both** Loop Start and Loop End, deliberately: every reader on a materialized input port replays that port's states independently, so a second link would deliver the loop state twice per iteration (double `update`, double back-edge), and a Loop Start additionally needs a single reader for the scheduler to resolve its bookkeeping URIs from. The scheduler's `require` stays as a defense-in-depth backstop for programmatically built plans (the discussion's author builds `WorkflowContent` directly, bypassing the GUI). Note: a saved workflow that already has two links into a loop operator will now be flagged invalid in the editor rather than failing at run time — which is the intent, since such a plan cannot execute today either. ### Any related issues, documentation, discussions? Addresses the GUI half of [discussion #6966](https://github.com/apache/texera/discussions/6966). ### How was this PR tested? `LoopStartOpDescSpec` and `LoopEndOpDescSpec` each gain a case pinning `inputPorts.head.disallowMultiLinks shouldBe true` (both fail before the change, 29/29 pass after). `scalafmtCheckAll` + `scalafixAll --check` clean on Java 17. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 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]
