failing assertion while generating the flowGraphMap

[ysmaoui]

testing the latest 3.1.2 version
I am having currently the issue that the following assertion is failing
https://github.com/gdemengin/pipeline-logparser/blob/3.1.2/vars/logparser.groovy#L69

with some debugging, it looks like the FlowEndNode can also have a null enclosingId ( not only the FlowStartNode ) and the start is not null
for example I am getting:

08:39:29  it.getDisplayName(): End of Pipeline
08:39:29  it.getTypeDisplayName(): End of Pipeline
08:39:29  it.getClass(): class org.jenkinsci.plugins.workflow.graph.FlowEndNode
08:39:29  it.enclosingId:  null
08:39:29  start: 2

is this happening because I am trying to get the logs of an already finished pipeline?

[gdemengin]

well I ran into this problem a few weeks ago and did not know yet what to make of it

I made this branch to avoid the error https://github.com/gdemengin/pipeline-logparser/tree/corruptflow

can you try it ?

it did hide the error for me ... but the logs I got from the parsing were incomplete

so I was not really sure it should become the default behavior because I suspect there was some kind of corruption of the flowgraph of a specific run:

• my instance had crashed after disk space got exhausted and the error started happening right after It was restarted
  • in this case I was reparsing an old run (that I was able to parse without error before the crash)
  • it happens on a few jobs actually (all corrupted after the crash)
  • I could never reproduce the issue on new runs of the same jobs
• and having no enclosingId on a node (FlowEndNode or any other node) means that this node has no parent so it's not part of the flowgraph : that should never happen. and it's likely that the information parsed from the run (logs, branches, etc) might be incomplete
  • or maybe I'm wrong and it can happen in normal conditions : do you have an example of pipeline causing this FlowEndNode with no enclosingId ?

assuming it's a corruption, I'm thinking maybe the behavior in that branch should become an option

• one might prefer to know that parsing failed instead of risking to get partial information : then the assert is fine. and I think it should remain the default behavior
• but one might prefer to ignore the error and get as much as possible from the parsing (even if incomplete) because it's better than nothing

I did not do it (yet) cause this library already has too many/too complicated options and this one will be tricky to explain (and to find a good name : I guess I would call it allowCorruptFlow with default false)

what do you think, should we add an option for that ?

[ysmaoui]

hi @gdemengin

according to the docs
https://javadoc.jenkins.io/plugin/workflow-api/org/jenkinsci/plugins/workflow/graph/FlowNode.html#getEnclosingId--

both FlowStartNode and FlowEndNode should have a null encolsingId ( I am not sure about the logic why though )

But I suspect that usually if you try to get the logs while the build is still running the flowEndNode would be still not created ( so not visited in the loop and the assertion would not fail )
and if you try to get the Logs of an already finished Jenkins build, the flowEndNode would have been created ( pipeline ended ) and it should have null enclosingId according to the docs ( so the assertion fails )

[gdemengin]

ok agreed. I'll propose a change asap