[JENKINS-72771] Single running parallel branch missing parent parallel block.

[jenkins-infra-bot]

When there is a single, running branch of a pipeline, the StandardChunkVisitor doesn't trigger `parallelEnd` or `parallelStart` for it's parent block.

This works:

node {
    parallel([
"A": {
    stage("Build") {
echo("Build A")
    }
    stage("Test") {
parallel([
    "A1" : {
       echo("Test A1")
    },
    "A2" : {
       echo("Test A2")
    }
])
    }
},
"B": {
    stage("Build") {
echo("Build B")
    }
    parallel([
"B1" : {
   echo("Test B1")
   sleep(60)
},
"B2" : {
   echo("Test B2")
   sleep(60;
}
    ])
}
    ])
} 

We get `A<-A1` and `B<-B1,B2`.

This doesn't:

node {
    parallel([
"A": {
    stage("Build") {
echo("Build A")
    }
    stage("Test") {
parallel([
    "A1" : {
       echo("Test A1")
    },
    "A2" : {
       echo("Test A2")
    }
])
    }
},
"B": {
    stage("Build") {
echo("Build B")
    }
    parallel([
"B1" : {
   echo("Test B1")
   sleep(60)
},
    ])
}
    ])
} 

(`B1` becomes a sibling of `A` - `B` is not listed in the graph until the build completes).

It feels like this would have been reported already, but I can't find an issue - so raising just in case.

Update:
More specifically, in the second Pipeline - `parallelBranchEnd/parallelBranchStart` don't get called for `B` whilst the Pipeline is still executing. This is not the case once the pipeline is finished or in the first example.

---

Originally reported by canuck1987, imported from: Single running parallel branch missing parent parallel block.

• status: Open
• priority: Minor
• component(s): pipeline-graph-analysis-plugin
• resolution: Unresolved
• votes: 0
• watchers: 4
• imported: 20251223-222157

Raw content of original issue

When there is a single, running branch of a pipeline, the StandardChunkVisitor doesn't trigger `parallelEnd` or `parallelStart` for it's parent block.

This works:


node {
    parallel([
        "A": {
            stage("Build") {
                echo("Build A")
            }
            stage("Test") {
                parallel([
                    "A1" : {
                       echo("Test A1")
                    },
                    "A2" : {
                       echo("Test A2")
                    }
                ])
            }
        },
        "B": {
            stage("Build") {
                echo("Build B")
            }
            parallel([
                "B1" : {
                   echo("Test B1")
                   sleep(60)
                },
                "B2" : {
                   echo("Test B2")
                   sleep(60;
                }
            ])
        }
    ])
} 


We get `A<-A1` and `B<-B1,B2`.
This doesn't:

node {
    parallel([
        "A": {
            stage("Build") {
                echo("Build A")
            }
            stage("Test") {
                parallel([
                    "A1" : {
                       echo("Test A1")
                    },
                    "A2" : {
                       echo("Test A2")
                    }
                ])
            }
        },
        "B": {
            stage("Build") {
                echo("Build B")
            }
            parallel([
                "B1" : {
                   echo("Test B1")
                   sleep(60)
                },
            ])
        }
    ])
} 


(`B1` becomes a sibling of `A` - `B` is not listed in the graph until the build completes).
It feels like this would have been reported already, but I can't find an issue - so raising just in case.
Update:
More specifically, in the second Pipeline - `parallelBranchEnd/parallelBranchStart` don't get called for `B` whilst the Pipeline is still executing. This is not the case once the pipeline is finished or in the first example.

environment

Jenkins: 2.440<br/>
Pipeline Graph View Plugin (pipeline-graph-view): 999999-SNAPSHOT (private-d6f73ada-timb)<br/>
Apache HttpComponents Client 4.x API Plugin (apache-httpcomponents-client-4-api): 4.5.14-208.v438351942757<br/>
bouncycastle API Plugin (bouncycastle-api): 2.30.1.77-225.v26ea_c9455fd9<br/>
Branch API Plugin (branch-api): 2.1144.v1425d1c3d5a_7<br/>
Caffeine API Plugin (caffeine-api): 3.1.8-133.v17b_1ff2e0599<br/>
Folders Plugin (cloudbees-folder): 6.858.v898218f3609d<br/>
commons-lang3 v3.x Jenkins API Plugin (commons-lang3-api): 3.13.0-62.v7d18e55f51e2<br/>
Credentials Binding Plugin (credentials-binding): 657.v2b_19db_7d6e6d<br/>
Credentials Plugin (credentials): 1311.vcf0a_900b_37c2<br/>
Display URL API (display-url-api): 2.200.vb_9327d658781<br/>
Durable Task Plugin (durable-task): 543.v262f6a_803410<br/>
Git client plugin (git-client): 4.6.0<br/>
Git plugin (git): 5.2.1<br/>
GitHub API Plugin (github-api): 1.318-461.v7a_c09c9fa_d63<br/>
GitHub Branch Source Plugin (github-branch-source): 1772.va_69eda_d018d4<br/>
GitHub plugin (github): 1.37.3.1<br/>
Gson API Plugin (gson-api): 2.10.1-15.v0d99f670e0a_7<br/>
Instance Identity (instance-identity): 185.v303dc7c645f9<br/>
Ionicons API (ionicons-api): 56.v1b_1c8c49374e<br/>
Jackson 2 API Plugin (jackson2-api): 2.16.1-373.ve709c6871598<br/>
Jakarta Activation API (jakarta-activation-api): 2.0.1-3<br/>
Jakarta Mail API (jakarta-mail-api): 2.0.1-3<br/>
JavaBeans Activation Framework (JAF) API (javax-activation-api): 1.2.0-6<br/>
JavaMail API (javax-mail-api): 1.6.2-9<br/>
JAXB plugin (jaxb): 2.3.9-1<br/>
Java JSON Web Token (JJWT) Plugin (jjwt-api): 0.11.5-77.v646c772fddb_0<br/>
JSON Path API Plugin (json-path-api): 2.8.0-21.v8b_7dc8b_1037b_<br/>
Mailer Plugin (mailer): 463.vedf8358e006b_<br/>
Metrics Plugin (metrics): 4.2.18-442.v02e107157925<br/>
Mina SSHD API :: Common (mina-sshd-api-common): 2.12.0-90.v9f7fb_9fa_3d3b_<br/>
Mina SSHD API :: Core (mina-sshd-api-core): 2.12.0-90.v9f7fb_9fa_3d3b_<br/>
OkHttp Plugin (okhttp-api): 4.11.0-157.v6852a_a_fa_ec11<br/>
Pipeline: Build Step (pipeline-build-step): 540.vb_e8849e1a_b_d8<br/>
Pipeline Graph Analysis Plugin (pipeline-graph-analysis): 202.va_d268e64deb_3<br/>
Pipeline: Groovy Libraries (pipeline-groovy-lib): 700.v0e341fa_57d53<br/>
Pipeline: Input Step (pipeline-input-step): 477.v339683a_8d55e<br/>
Pipeline: Model API (pipeline-model-api): 2.2168.vf921b_4e72c73<br/>
Pipeline: Declarative (pipeline-model-definition): 2.2168.vf921b_4e72c73<br/>
Pipeline: Declarative Extension Points API (pipeline-model-extensions): 2.2168.vf921b_4e72c73<br/>
Pipeline: Stage Step (pipeline-stage-step): 305.ve96d0205c1c6<br/>
Pipeline: Stage Tags Metadata (pipeline-stage-tags-metadata): 2.2168.vf921b_4e72c73<br/>
Plain Credentials Plugin (plain-credentials): 143.v1b_df8b_d3b_e48<br/>
SCM API Plugin (scm-api): 683.vb_16722fb_b_80b_<br/>
Script Security Plugin (script-security): 1313.v7a_6067dc7087<br/>
SnakeYAML API Plugin (snakeyaml-api): 2.2-111.vc6598e30cc65<br/>
SSH Credentials Plugin (ssh-credentials): 308.ve4497b_ccd8f4<br/>
Structs Plugin (structs): 337.v1b_04ea_4df7c8<br/>
Token Macro Plugin (token-macro): 400.v35420b_922dcb_<br/>
Trilead API Plugin (trilead-api): 2.133.vfb_8a_7b_9c5dd1<br/>
Variant Plugin (variant): 60.v7290fc0eb_b_cd<br/>
Pipeline: API (workflow-api): 1283.v99c10937efcb_<br/>
Pipeline: Basic Steps (workflow-basic-steps): 1042.ve7b_140c4a_e0c<br/>
Pipeline: Groovy (workflow-cps): 3837.v305192405b_c0<br/>
Pipeline: Nodes and Processes (workflow-durable-task-step): 1313.vcb_970b_d2a_fb_3<br/>
Pipeline: Job (workflow-job): 1385.vb_58b_86ea_fff1<br/>
Pipeline: Multibranch (workflow-multibranch): 773.vc4fe1378f1d5<br/>
Pipeline: SCM Step (workflow-scm-step): 415.v434365564324<br/>
Pipeline: Step API (workflow-step-api): 657.v03b_e8115821b_<br/>
Pipeline: Supporting APIs (workflow-support): 865.v43e78cc44e0d

[jenkins-infra-bot]

timja:

• Original comment link
• Raw content of original comment:

  (jglick / Devin (can't find his jira name) appear to be the maintainer)
  
  This came from Add Tree Scanner pipeline-graph-view-plugin#285
  

(jglick / Devin (can't find his jira name) appear to be the maintainer)

This came from jenkinsci/pipeline-graph-view-plugin#285

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  dnusbaum that is
  

dnusbaum that is

[jenkins-infra-bot]

dnusbaum:

• Original comment link
• Raw content of original comment:

  IMO, ForkScanner and related APIs like ChunkFinder are just fundamentally broken for non-trivial cases, particularly when used on incomplete builds, and should be avoided. I would also probably avoid pipeline-graph-analysis in general in newly written code. 
  
  Instead, I would use DepthFirstScanner as mentioned in Add warning to ForkScanner Javadoc describing potential issues when using it with multiple heads workflow-api-plugin#306.
  
  To elaborate, I found a few serious issues last year while trying to make ForkScanner work with a proprietary Pipeline visualization I worked on (see the video on https://docs.cloudbees.com/docs/cloudbees-ci/latest/pipelines/cloudbees-pipeline-explorer-plugin, timestamp roughly 2:08 shows the relevant functionality), including Prevent ForkScanner from visiting nodes more than once in some cases for in-progress builds with nested parallelism workflow-api-plugin#287, Prevent ForkScanner from skipping nodes when scanning incomplete parallel steps that only have a single branch workflow-api-plugin#302 (that might be the case in the description here), and Make ForkScanner visit parallel branches for incomplete parallel steps in a more consistent order (ideally reverse declaration order) workflow-api-plugin#305. Maybe with enough time, someone could find a way to make things work in all of the edge cases, but for me it was just way simpler to use DepthFirstScanner directly to avoid all of the problems.
  
  The core logic in FlowGraphTable might be useful as a starting point just to show you how to build up a basic tree, but would need to be adapted for your specific use case (e.g. filtering out stuff besides stage, parallel, and parallel branches).
  
  
  
  

IMO, ForkScanner and related APIs like ChunkFinder are just fundamentally broken for non-trivial cases, particularly when used on incomplete builds, and should be avoided. I would also probably avoid pipeline-graph-analysis in general in newly written code.

Instead, I would use DepthFirstScanner as mentioned in jenkinsci/workflow-api-plugin#306.

To elaborate, I found a few serious issues last year while trying to make ForkScanner work with a proprietary Pipeline visualization I worked on (see the video on https://docs.cloudbees.com/docs/cloudbees-ci/latest/pipelines/cloudbees-pipeline-explorer-plugin, timestamp roughly 2:08 shows the relevant functionality), including jenkinsci/workflow-api-plugin#287, jenkinsci/workflow-api-plugin#302 (that might be the case in the description here), and jenkinsci/workflow-api-plugin#305. Maybe with enough time, someone could find a way to make things work in all of the edge cases, but for me it was just way simpler to use DepthFirstScanner directly to avoid all of the problems.

The core logic in FlowGraphTable might be useful as a starting point just to show you how to build up a basic tree, but would need to be adapted for your specific use case (e.g. filtering out stuff besides stage, parallel, and parallel branches).

[jenkins-infra-bot]

canuck1987:

• Original comment link
• Raw content of original comment:

  > IMO, ForkScanner and related APIs like ChunkFinder are just fundamentally broken for non-trivial cases
  
  If this is the case, wouldn't it be best to mark it deprecated so people don't try and use it?
  

> IMO, ForkScanner and related APIs like ChunkFinder are just fundamentally broken for non-trivial cases

If this is the case, wouldn't it be best to mark it deprecated so people don't try and use it?

[jenkins-infra-bot]

canuck1987:

• Original comment link
• Raw content of original comment:

  Are there docs or a good example of something creating a graph using `DepthFirstScanner`?
  
  FWIW PipelineGraphView uses SimpleChunkVisitor because BlueOcean did - I think everyone would prefer a simpler/more reliable method.
  

Are there docs or a good example of something creating a graph using `DepthFirstScanner`?

FWIW PipelineGraphView uses SimpleChunkVisitor because BlueOcean did - I think everyone would prefer a simpler/more reliable method.

[jenkins-infra-bot]

dnusbaum:

• Original comment link
• Raw content of original comment:

  
  If this is the case, wouldn't it be best to mark it deprecated so people don't try and use it?
  
  Yes, probably so. I considered doing that in Add warning to ForkScanner Javadoc describing potential issues when using it with multiple heads workflow-api-plugin#306 when I added the warning to the Javadoc, but it does work ok for completed builds as far as I know, so I wasn't sure about it.
  
  
  Are there docs or a good example of something creating a graph using `DepthFirstScanner`?
  
  The best available example for this case is I think FlowGraphTable like I mentioned (I think that code can be simplified depending on your requirements, but you might be able to use it directly). Basically the idea is to traverse all of the nodes to create a tree, filtering it as needed, and then you then visualize it as desired (e.g. as a tree directly, or flip it on its side to get something like Blue Ocean). (Also, depending on how you want your visualization to work, maybe building a tree is unnecessary. For example, if you are want to display circles for stages/parallel branches with lines between them, maybe you can just iterate over the graph directly, adding metadata as needed, and then use something like d3 to build the layout automatically.)
  
  
  FWIW PipelineGraphView uses SimpleChunkVisitor because BlueOcean did
  
  Yes, I was not around for the original creation of Blue Ocean, so I do not know why it was implemented the way it was, but I would not use it as a reference for new code.
  

If this is the case, wouldn't it be best to mark it deprecated so people don't try and use it?

Yes, probably so. I considered doing that in jenkinsci/workflow-api-plugin#306 when I added the warning to the Javadoc, but it does work ok for completed builds as far as I know, so I wasn't sure about it.

Are there docs or a good example of something creating a graph using `DepthFirstScanner`?

The best available example for this case is I think FlowGraphTable like I mentioned (I think that code can be simplified depending on your requirements, but you might be able to use it directly). Basically the idea is to traverse all of the nodes to create a tree, filtering it as needed, and then you then visualize it as desired (e.g. as a tree directly, or flip it on its side to get something like Blue Ocean). (Also, depending on how you want your visualization to work, maybe building a tree is unnecessary. For example, if you are want to display circles for stages/parallel branches with lines between them, maybe you can just iterate over the graph directly, adding metadata as needed, and then use something like d3 to build the layout automatically.)

FWIW PipelineGraphView uses SimpleChunkVisitor because BlueOcean did

Yes, I was not around for the original creation of Blue Ocean, so I do not know why it was implemented the way it was, but I would not use it as a reference for new code.

[jenkins-infra-bot]

canuck1987:

• Original comment link
• Raw content of original comment:

  HI Devin,
  
  Thanks for your suggestion of using the DepthFirstScanner (it's something I looked at before, but assume was wasn't used as it an older/slower traversal method). I found it better (for me) to get the nodes, order them by id and iterate over them - the DepthFirstScanner sent a lot of nodes to the end of the iteration, which tripped me up for a while.
  
  I've updated my PR to move the Graph View to use new graph building method built on DepthFirstScanner: Add Tree Scanner pipeline-graph-view-plugin#285 (feel free to comment).
  
  Also (for those finding this bug in the future) the readme in worflow-api-plugin is useful - and it's 100% right about needing to read the StatusAndTiming API in order to use it properly.
  

HI Devin,

Thanks for your suggestion of using the DepthFirstScanner (it's something I looked at before, but assume was wasn't used as it an older/slower traversal method). I found it better (for me) to get the nodes, order them by id and iterate over them - the DepthFirstScanner sent a lot of nodes to the end of the iteration, which tripped me up for a while.

I've updated my PR to move the Graph View to use new graph building method built on DepthFirstScanner: jenkinsci/pipeline-graph-view-plugin#285 (feel free to comment).

Also (for those finding this bug in the future) the readme in worflow-api-plugin is useful - and it's 100% right about needing to read the StatusAndTiming API in order to use it properly.

[jenkins-infra-bot]

dnusbaum:

• Original comment link
• Raw content of original comment:

  Oh, yeah sorry I forgot about that readme. FWIW, I would be wary of using `StatusAndTiming.computeChunkStatus2`. As I recall, it more or less assumes that you are passing nodes exactly how `ForkScanner.visitSimpleChunks` would give them to you, so if you pass other things, the behavior may be anomalous. If it works for you though, great. If you run into issues, I would extract whatever parts of its logic you care about for your visualization into your plugin so that you can control the behavior.
  

Oh, yeah sorry I forgot about that readme. FWIW, I would be wary of using `StatusAndTiming.computeChunkStatus2`. As I recall, it more or less assumes that you are passing nodes exactly how `ForkScanner.visitSimpleChunks` would give them to you, so if you pass other things, the behavior may be anomalous. If it works for you though, great. If you run into issues, I would extract whatever parts of its logic you care about for your visualization into your plugin so that you can control the behavior.