feat: allow Multi-Link on Input Ports by aglinxinyuan · Pull Request #4342 · apache/texera

aglinxinyuan · 2026-03-31T23:42:50Z

What changes were proposed in this PR?

Enabling multi-link support for input ports.
Made several format improvements.

Before the change	After the change

Any related issues, documentation, discussions?

Closes #4329

How was this PR tested?

Tested manually.

Was this PR authored or co-authored using generative AI tooling?

No.

Copilot

Pull request overview

This PR enables multi-link support on input ports in the workflow editor, aligning input-port connection behavior with existing output-port multi-link behavior (closes #4329).

Changes:

Allows multiple links to connect to the same input port in the workflow editor connection validator.
Updates workflow validation so input ports no longer require exactly one incoming link.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
frontend/src/app/workspace/service/validation/validation-workflow.service.ts	Adjusts operator connection validation logic for input ports to permit multi-link.
frontend/src/app/workspace/component/workflow-editor/workflow-editor.component.ts	Relaxes UI connection validation to allow additional links into already-connected input ports.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

frontend/src/app/workspace/service/validation/validation-workflow.service.ts

frontend/src/app/workspace/component/workflow-editor/workflow-editor.component.ts

…low.service.ts Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Xinyuan Lin <xinyual3@uci.edu>

chenlica · 2026-04-01T07:09:16Z

@Xiao-zhen-Liu Please review it.

Xiao-zhen-Liu

Left a comment.

frontend/src/app/workspace/service/validation/validation-workflow.service.ts

aglinxinyuan · 2026-04-03T05:35:01Z

Per offline discussion, we will change the flag from "allowMultiInputs" to "disallowMultiInputs", and disallow multi-inputs on visualization operators.

Xiao-zhen-Liu

I thought we agreed on letting disallowMultiInput be false by default but true for visualization operators. Your changes do not seem to reflect that.

frontend/src/app/workspace/service/operator-metadata/mock-operator-metadata.data.ts

...tor/src/main/scala/org/apache/texera/amber/operator/metadata/OperatorMetadataGenerator.scala

This reverts commit b498313.

This reverts commit 8918de0.

Xiao-zhen-Liu

LGTM

Yicong-Huang

I left some comments. @aglinxinyuan please add some more description on the PR itself, so we know the changes in high level.

I find many unexpected changes, in my opinion they should not be in this PR, according to the current description. @chenlica please chime in on review process.

Yicong-Huang · 2026-04-11T00:40:46Z

common/config/src/main/resources/storage.conf

                uri-without-scheme = "localhost:5432/texera_iceberg_catalog"
                uri-without-scheme = ${?STORAGE_ICEBERG_CATALOG_POSTGRES_URI_WITHOUT_SCHEME}

-                username = "texera"


@aglinxinyuan @Xiao-zhen-Liu are these changes intentional? it is not mentioned in PR description.

This change is unintentional, but it has no effect since it's just a placeholder.

we should avoid this kind of unintentional change. whether it has effect or not is debatable. for example, for other developers they may have conflict when they pull the change that they need to deal with. so that's also "effect".

I totally agree. It's definitely a mistake. Besides this one, all the other changes are intentional.

Yicong-Huang · 2026-04-11T00:41:39Z

...on/workflow-operator/src/main/scala/org/apache/texera/amber/operator/dummy/DummyOpDesc.scala

          )
      }
    } else {
-      List(InputPort(PortIdentity(), allowMultiLinks = true))


I think we need to keep the PortIdentity() part. PortIdentity() returns PortIdentity(0).

It will return the same result.

I don't think so. do you have a test result to show they are equal?

PortIdentity(0) is not equal to 0 or null.

Yes. I will provide test result later. If it's not the same, the test case should fail.

InputPort() defaults to InputPort(PortIdentity()), which is equivalent to InputPort(PortIdentity(0)).

We use InputPort() consistently elsewhere; the only reason PortIdentity() was previously passed here was to explicitly set the positional argument.

Yicong-Huang · 2026-04-11T00:42:35Z

...ain/scala/org/apache/texera/amber/operator/visualization/bubbleChart/BubbleChartOpDesc.scala

      "a 3D Scatter Plot; Bubbles are graphed using x and y labels, and their sizes determined by a z-value.",
-      OperatorGroupConstants.VISUALIZATION_BASIC_GROUP,
-      inputPorts = List(InputPort()),
-      outputPorts = List(OutputPort(mode = OutputMode.SINGLE_SNAPSHOT))


why do we have those changes on the output port? I thought the PR is only about input port?

It's just a refactor. The input port and the output port is still the same. The duplicate port definition is moved to the parent class.

Let's separate refactor and feature change. even if you combine them, it will be good to annotate on the PR description. other wise this is unexpected change.

Yicong-Huang · 2026-04-11T00:42:52Z

...ain/scala/org/apache/texera/amber/operator/visualization/bulletChart/BulletChartOpDesc.scala

  @JsonSchemaTitle("Steps")
  @JsonPropertyDescription("Optional: Each step includes a start and end value e.g., 0, 100.")
-  var steps: JList[BulletChartStepDefinition] = new ArrayList[BulletChartStepDefinition]()
+  var steps: JList[BulletChartStepDefinition] = new util.ArrayList[BulletChartStepDefinition]()


why this change?

Done by formatter.

this is unnecessary change. if it is caused by formatter then we should fix the formatter. does our formatter give inconsistent results across different runs?

I also checked, it's a better practice.

aglinxinyuan · 2026-04-11T01:24:50Z

I left some comments. @aglinxinyuan please add some more description on the PR itself, so we know the changes in high level.

I find many unexpected changes, in my opinion they should not be in this PR, according to the current description. @chenlica please chime in on review process.

All the changes are intentional expect one line. That line is also a placeholder so it has no effect on the codebase. All the changes in the PR are being discussed and reviewed. Every reviewer has different standards, so it's very subjective.

Yicong-Huang · 2026-04-11T01:35:41Z

I left some comments. @aglinxinyuan please add some more description on the PR itself, so we know the changes in high level.
I find many unexpected changes, in my opinion they should not be in this PR, according to the current description. @chenlica please chime in on review process.

All the changes are intentional expect one line. That line is also a placeholder so it has no effect on the codebase. All the changes in the PR are being discussed and reviewed. Every reviewer has different standards, so it's very subjective.

Please minimize the change. even if a change has no "big effect" it should be avoided, if it is unrelated to the PR's scope. Not to mention there is indeed unintentional change included in the PR that should not have been merged.

chenlica · 2026-04-11T03:22:53Z

I know the PR was already merged. Sorry for chiming in later.

I prefer to treat formatting changes in a separate PR, and only keep logical changes in this PR. @aglinxinyuan Do you agree?

aglinxinyuan · 2026-04-11T05:31:41Z

I know the PR was already merged. Sorry for chiming in later.

I prefer to treat formatting changes in a separate PR, and only keep logical changes in this PR. @aglinxinyuan Do you agree?

That’s not the practice we were following in the past. We usually make minor fixes like formatting along with major changes in a single PR. Of course, it is possible to make every single line of change a separate PR, and they would still be logically correct, but it would dramatically decrease productivity. Since I’m touching those files, I feel it makes sense for me to improve some formatting issues I’ve seen in the same file. Of course, I don’t have to do that, and it doesn’t make much sense to create a separate PR just for that.

Yicong-Huang · 2026-04-11T06:29:20Z

We usually make minor fixes like formatting along with major changes in a single PR.

That's fine, but if you did that, please mention it in PR description so reviewers won't find it surprising.

it is possible to make every single line of change a separate PR, and they would still be logically correct, but it would dramatically decrease productivity.

It is a balance. besides the PR author's effort, we also need to consider the changes you are making would affect others who work on the same file, and also the time reviewers are putting on the PR. so ideally it is always better to minimize change so that the conflicts are small, and reviews are easier. For instance, as a reviewer if I know you are only change format then it's a simple stamp from me. If you mix formatting and logic changes within the same pr, and does not let me know up front, then my review will be full of questions like "why do you change this, this feels unrelated to the PR". which also waste time of the team.

Of course, I don’t have to do that, and it doesn’t make much sense to create a separate PR just for that.

Actually, making another PR for formatting only changes, or comment-only changes, are recommended. they can be marked as minor PRs, and can make review easier.

aglinxinyuan · 2026-04-11T08:08:43Z

We usually make minor fixes like formatting along with major changes in a single PR.

That's fine, but if you did that, please mention it in PR description so reviewers won't find it surprising.

it is possible to make every single line of change a separate PR, and they would still be logically correct, but it would dramatically decrease productivity.

It is a balance. besides the PR author's effort, we also need to consider the changes you are making would affect others who work on the same file, and also the time reviewers are putting on the PR. so ideally it is always better to minimize change so that the conflicts are small, and reviews are easier. For instance, as a reviewer if I know you are only change format then it's a simple stamp from me. If you mix formatting and logic changes within the same pr, and does not let me know up front, then my review will be full of questions like "why do you change this, this feels unrelated to the PR". which also waste time of the team.

Of course, I don’t have to do that, and it doesn’t make much sense to create a separate PR just for that.

Actually, making another PR for formatting only changes, or comment-only changes, are recommended. they can be marked as minor PRs, and can make review easier.

I'm aware of and agree with those principles. It really comes down to balance, which is why I mentioned earlier that it's very subjective.

In fact, I already separated the major related formatting changes into three PRs to make the review process easier: #4332, #4334, and #4336. The remaining formatting changes, in my judgment, are too minor to warrant a separate PR or even to be mentioned in the PR description.

init

0457987

aglinxinyuan requested a review from Xiao-zhen-Liu March 31, 2026 23:42

aglinxinyuan self-assigned this Mar 31, 2026

Copilot AI review requested due to automatic review settings March 31, 2026 23:42

github-actions bot added the frontend Changes related to the frontend GUI label Mar 31, 2026

Copilot started reviewing on behalf of aglinxinyuan March 31, 2026 23:43 View session

Merge branch 'main' into xinyuan-union

5b36a66

Copilot AI reviewed Mar 31, 2026

View reviewed changes

Update frontend/src/app/workspace/service/validation/validation-workf…

cd43d9f

…low.service.ts Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Xinyuan Lin <xinyual3@uci.edu>

fix test

e602ae8

Xiao-zhen-Liu reviewed Apr 2, 2026

View reviewed changes

frontend/src/app/workspace/service/validation/validation-workflow.service.ts Outdated Show resolved Hide resolved

Merge branch 'main' into xinyuan-union

4d2035e

aglinxinyuan marked this pull request as draft April 3, 2026 05:33

aglinxinyuan marked this pull request as ready for review April 3, 2026 05:35

aglinxinyuan marked this pull request as draft April 3, 2026 05:35

aglinxinyuan added 2 commits April 2, 2026 22:35

Merge branch 'main' into xinyuan-union

4bfa9fb

update

39ced05

github-actions bot added the common label Apr 4, 2026

update

d073642

github-actions bot added engine python labels Apr 5, 2026

aglinxinyuan added 4 commits April 5, 2026 17:17

update

1c1f97b

update

9d4a640

update

6116d18

update

8918de0

aglinxinyuan marked this pull request as ready for review April 6, 2026 02:10

update

b498313

Xiao-zhen-Liu requested changes Apr 6, 2026

View reviewed changes

frontend/src/app/workspace/service/operator-metadata/mock-operator-metadata.data.ts Outdated Show resolved Hide resolved

Xiao-zhen-Liu reviewed Apr 6, 2026

View reviewed changes

...tor/src/main/scala/org/apache/texera/amber/operator/metadata/OperatorMetadataGenerator.scala Outdated Show resolved Hide resolved

Xiao-zhen-Liu reviewed Apr 6, 2026

View reviewed changes

...tor/src/main/scala/org/apache/texera/amber/operator/metadata/OperatorMetadataGenerator.scala Outdated Show resolved Hide resolved

aglinxinyuan added 4 commits April 6, 2026 13:05

update

7fcf839

Revert "update"

09d4b2e

This reverts commit b498313.

Revert "update"

549ad07

This reverts commit 8918de0.

update

3d6ad85

Xiao-zhen-Liu approved these changes Apr 6, 2026

View reviewed changes

aglinxinyuan added 5 commits April 8, 2026 18:06

update

d63958a

update

cc6d497

update

d2ebecb

update

ae1a0aa

Merge branch 'main' into xinyuan-union

96e0e3b

aglinxinyuan enabled auto-merge (squash) April 9, 2026 07:02

aglinxinyuan added 7 commits April 9, 2026 15:44

Merge branch 'main' into xinyuan-union

fd29f50

Merge branch 'main' into xinyuan-union

c3cd887

fix fmt

58e1cec

Merge remote-tracking branch 'origin/xinyuan-union' into xinyuan-union

1fbece2

fix fmt

267cf46

local

43f8a5a

update

9d68e14

aglinxinyuan merged commit dffd031 into main Apr 11, 2026
11 checks passed

aglinxinyuan deleted the xinyuan-union branch April 11, 2026 00:03

Yicong-Huang reviewed Apr 11, 2026

View reviewed changes

Conversation

aglinxinyuan commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes were proposed in this PR?

Any related issues, documentation, discussions?

How was this PR tested?

Was this PR authored or co-authored using generative AI tooling?

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

chenlica commented Apr 1, 2026

Uh oh!

Xiao-zhen-Liu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

aglinxinyuan commented Apr 3, 2026

Uh oh!

Xiao-zhen-Liu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Xiao-zhen-Liu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Yicong-Huang left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aglinxinyuan commented Apr 11, 2026

Uh oh!

Yicong-Huang commented Apr 11, 2026

Uh oh!

chenlica commented Apr 11, 2026

Uh oh!

aglinxinyuan commented Apr 11, 2026

Uh oh!

Yicong-Huang commented Apr 11, 2026

Uh oh!

aglinxinyuan commented Mar 31, 2026 •

edited

Loading