Skip to content

Conversation

@Mrhs121
Copy link
Contributor

@Mrhs121 Mrhs121 commented Jan 18, 2026

Purpose of the pull request

close #17873

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.

(or)

This pull request is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(or)

Pull Request Notice

Pull Request Notice

If your pull request contains incompatible change, you should also add it to docs/docs/en/guide/upgrade/incompatible.md

@SbloodyS SbloodyS added the improvement make more easy to user or prompt friendly label Jan 19, 2026
@SbloodyS SbloodyS added this to the 3.4.1 milestone Jan 19, 2026
@sonarqubecloud
Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
50.0% Coverage on New Code (required ≥ 60%)

See analysis details on SonarQube Cloud

Comment on lines +432 to +434
if (dependentItem.getDefinitionCode() == workflowDefinitionCode) {
throw new ServiceException(Status.WORKFLOW_NODE_HAS_CYCLE);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: Maybe only check the dependeny type is DEPENDENT_ON_WORKFLOW? I am not clear if we shouldn't support dependent a task is in the same workflow.

And it's better to provide a method to check if the workflow exist cycle, since there are some extra case may stiil cause cycle, e.g. dependent a subworkflow node, the subworkflow contains a subworkflow task point to the parent workflow.

Suggested change
if (dependentItem.getDefinitionCode() == workflowDefinitionCode) {
throw new ServiceException(Status.WORKFLOW_NODE_HAS_CYCLE);
}
if (dependentItem.getDependentType() == DependentType.DEPENDENT_ON_WORKFLOW && dependentItem.getDefinitionCode() == workflowDefinitionCode) {
throw new ServiceException(Status.WORKFLOW_NODE_HAS_CYCLE);
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your review—your suggestion makes sense.
However, I’m concerned that this change could break the existing design, since the current documentation explicitly permits this configuration of the dependent node. I’m not yet sure which behavior should be considered correct; please see my comment for details: #17873 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Mrhs121 So we should not do any restrictions here, as there may be scenarios where the current workflow depends on the previous day's operations? It might be better to let users control all of this themselves.

So this PR only fix the lineage cycle?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backend improvement make more easy to user or prompt friendly

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Improvement][dolphinscheduler-api] A dependent node cannot depend on the workflow it is in

3 participants