Unexpected behaviour with /control/getVal

[ There is no forum category for UI commands (intercoms), so I chose what I chose. ]

I am encountering an unexpected behaviour with the /control/getVal command, which is causing user confusion. We have GetCurrentValue() implemented in most of our Messenger classes, to return the results of various configuration settings.

If we use the /control/getVal to get the value of one of our commands, the worker threads report back “command not found” on G4cerr, but the query goes through successfully. I’ve traced the error message to the function

G4String G4UImanager::GetCurrentValues(const char * aCommand)
  G4String theCommand = aCommand;
  savedCommand = treeTop->FindPath( theCommand );
  if( savedCommand == nullptr )
    G4cerr << "command not found" << G4endl;
    return G4String();
  return savedCommand->GetCurrentValue();

which is the only place anywhere in the G4 source where a bare “command not found” message is generated. Here’s a simple example which demonstrates what we’re seeing. For a simple macro in our framework,

/control/verbose 2
/CDMS/Physics/DMC          # This sets a flag "true"
/control/getVal isDMC /CDMS/Physics/DMC
/control/echo isDMC = {isDMC}
/run/beamOn 1

Up to the point of /run/beamOn, this produces correct output on the master thread:

/control/getVal isDMC /CDMS/Physics/DMC
/control/alias isDMC true
/control/echo isDMC = true
isDMC = true
--- G4CoupledTransportation is used 

(notice that having the flag set true returns the string “true”). But later, the worker thread reports something slightly different:

G4WT0 > /CDMS/Physics/DMC
G4WT0 > /control/getVal isDMC /CDMS/Physics/DMC
G4WT0 > command not found
G4WT0 > /control/alias isDMC true
G4WT0 > /control/echo isDMC = true
G4WT0 > isDMC = true
G4WT0 > /run/initialize
G4WT0 > /run/physicsModified

Notice the third line above. This message is generated in the code above when treeTop->FindPath("/CDMS/Physics/DMC") fails. But it apparently “didn’t” fail, because it got the right value string, set the alias, and the rest of the job proceeded successfully.

Also notice the first line above. The actual command itself was found and executed on the worker thread successfully, which also required a call to FindPath(), which apparently didn’t fail.

I hope that someone knowledgeable about the Geant4 intercoms code could help me to debug this and eliminate the spurious error message. Having every worker thread report back “command not found” can make people nervous that their jobs are not functioning correctly.