Do you mean on some runs the synthetic marker isn't there but on others it is, or during some runs, sometimes the marker is there but sometimes in the same run it isn't?

Upon further investigation, it appears that FlowNode was changed in late 2016 to no longer automatically persist/save when addAction(...) was called. So what seems to be happening is that the addAction call isn't persisting until the stage actually completes and gets persisted/saved anyway. Now we're trying to figure out what we should be doing in this scenario.

svanoort abayer Here is the logs you requested. I am printing StatusAndTiming.printNodes(run, true, true), that is with timing info and actions when chunk.getFirstNode().getDisplayName().equals("Declarative: Checkout SCM") is true.

https://gist.github.com/vivek/cf66ab4a6a135bf7115ecb0f388e25e2

1. Line 2 is printed when no TagsAction is found for "Declarative: Checkout SCM" stage
   #Line 23 is printed in later scan of flow nodes when no TagsAction is found for "Declarative: Checkout SCM" stage
2. [Line 64] Shows declarative plugin adding TagsAction. and then Line 66 shows BO printing in its next scan the TagsAction key/value.

As you can see according to log, 1 and 2 happened before TagsAction was added later than declarative checkout stage.

So I guess you are scanning the nodes during that very very brief time between the creation of the FlowNode for the stage and the TagsAction getting attached. I don't know if there's any way to prevent there being that less-than-a-second gap.

I don't know if there's any way to prevent there being that less-than-a-second gap.

The only way is to use an asynchronous listener, so that event delivery is delayed until after the CPS VM runs a chunk, which would include the StepExecution.start that typically attaches actions before passing off control.

jglick - there'd still be some gap, right? Would that really be much less of a gap than what we have now, where the tagging is the first thing to be called inside the stage block?

This should only happen when the stage step is the current head, right?

Could we do a workaround to not render the stage until we have a step in it (or the stage has completed if empty)?

We could also provide the possible names for stages that could get marked as synthetic - then if it's one of those, you'd wait 'til it had a tag before rendering?

fwiw, just did some tests to see how much of a time difference the current approach vs GraphListener approach would be. Comparing from the time right before the stage call until the TagsAction is about to actually be attached, with 5 runs of each approach, we get an average of 40.8ms for the current approach to 15.4ms for the GraphListener approach. I gotta think that even if we cut down to that 15.4ms average, we'd still see Blue Ocean sometimes hitting this.

I've put up a PR of the first draft of the GraphListener approach at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/97. I'm fairly sure it's deeply flawed, but what the hell.