timeStamp in asynchronous QC (e.g. for TaskInterface::retrieveCondition(Any) calls)


I have a QC task that needs to read some condition data from CCDB (e.g. GLO/GRP/BunchFilling). When using that task in a synchronous workflow all is fine as I get the condition for the current running conditions (aka timeStamp=-1=now). But when running an asynchronous workflow (starting from CTFs), I’d want to use the timeStamp of the CTF I’m reading and not “now”. How can I achieve that ?



CTF injects to DataProcessingHeader the original creation time of the TF stored during sync. processing.
This was introduced in Nov.2021, for the CTFs of global runs of the pilot beam the time is injected from the special lookup table.

ok, yes, I guess I can use

auto creationTime = o2::header::get<o2::framework::DataProcessingHeader*>(some input)->creation;

in my task’s monitorData method. But then I’d have to implement the logic of knowing if the condition object is still valid or not, right ? (to know if I must call retrieveCondition again or not, as I guess it would not be a good idea to call it at each call to monitorData?)

There seem to be a start field in the Activity object : is it supposed to be useable for that purpose maybe ? (@bvonhall ?)

But why don’t you use the DPL CCDB fetcher?

Just answering this bit: yes, it should be that.

Well, because I don’t see how to tweak the inputs in the QC to add a condition one . Somehow the handling of the inputs is “automatic” in the QC framework. Or at least that’s how I’ve used them so far :wink:

but is it supposed to be filled by someone ?

I think so, but @pkonopka can say more.

@shahoian any advice on how to actually use the CCDB fetcher in a QC task ?

I guess one should request the CCDB inputs via jsons but I don’t know if/how one can indicate there that these are ccdbParamSpec types. @bvonhall or @eulisse may suggest.

This is how to specify a condition input in the string format, which we use in QC config files:

There seem to be a start field in the Activity object : is it supposed to be useable for that purpose maybe ? (@bvonhall ?)

Unfortunately this is a placeholder yet, since we were not able to get the SOR time from some central service. It will be done, but I can’t give you an ETA at this moment.

Hi Piotr,

Sorry for the late reaction.
So, if I understand correctly, if I were to put e.g. “geometry:GLO/Config/Geometry/0?lifetime=condition” in the query parameter of the datasource of my task, then the retrieval of the condition would be done automatically for me.
And also with the correct timestamp (that of the data being read) or not (yet) ?


Yes, that would be my expectation, though I have not tried it out myself, so please watch out for bugs.

Did you manage to run it? @shahoian @pkonopka @laphecet

We have faced the same problem with the FIT QC. @sbysiak