RootInTES not propagated from GaudiSequencer to GaudiAlgorithm

At some point between v31r0 and v32r0, setting the property RootInTES in a GaudiSequencer stopped being propagated to the member algorithms.

See https://its.cern.ch/jira/browse/LHCBGAUSS-1803

mentioned in merge request !990 (merged)

I created a MR with a reproducer. I'm suspecting of !904 (merged), but I'm not sure.

CC: @graven

According to git bisect the culprit is indeed from !904 (merged): 961f0130

I think that the problem comes from the change !904 (961f0130) and similar ones.

But didn't you fix that in b887e28c?

Actually, shouldn't the body of in 'from Tool' constructor which you fixed not also be in the body of the 'from Algorithm' constructor?

no, it shouldn't, as in the constructor for algorithm there is no ancestor... need more coffee. But it should be somewhere...

That's what I was noticing too... but I kind of fail to find why it was working before...

The only thing I spot is that RootInTES should be propagated here https://gitlab.cern.ch/gaudi/Gaudi/blob/master/GaudiAlg/src/lib/GaudiSequencer.cpp#L190

I'll go through it on Monday.

It has always been an issue that it is only propagated if the sequencer triggers the creation of the (sub)algorithm. If it was already created prior to the sequencer, it wouldn't work. Hence this entire magic propagation of properties should move out of the C++ code, and into the configuration. I just don't like from first principles that the C++ code modifies properties, as it does so after the configuration is made. So it's the equivalent of self-modifying code, which tends to be hard to understand / get right.

Instead, it is much easier on the python side to traverse the algorithms 'below' a sequencer, and set some of their properties...

Apologies for the long silence.

I think I found it.

The old behaviour (prior to !904 (merged)) was that the constructor of GaudiCommon was pulling the special properties out of the JobOptionsSvc. After !904 (merged) RootInTES became a normal property, so pulled from JOS at initialize (sysInitialize, actually).

The problem is that there's some too clever code in GaudiSequencer::decodeNames that:

1. add SubAlg.RootInTES to JOS
2. constructs SubAlg
3. remove SubAlg.RootInTES from JOS
4. some time later SubAlg gets initalized

The fix is on it's way.

assigned to @clemenci

closed via merge request !990 (merged)

mentioned in commit lhcb-nightlies/Gaudi@3468553f

changed milestone to %v33r1