How to deal with changing trigger scaling (per request)

[nicHoch]

with the new implemented option to change from trigger compression to trigger scaling we introduced a scaling factor (at the moment set to 30 as default)

Operation would like to change that value more often and ideally customised for (each) flare.
We need a way how this information is propagated into the processing pipeline reliably and reproducible.

@samaloney @drhlxiao ideas welcome

[nicHoch]

would it be a option to use the request id (rid) for that purpose?

at the moment the10 digit number is created that way: YYMMDD:#### > last 4 digits the unique number as id

could we change it to: YYMMDD:##:%% > only 2 digits (#) for id and 2 digits (%) for the scaling factor

if the 2 digits (100 requests) as unique id for a day is to low we could also use YYMMDD:###:% > where now the last % is a index for a constant scaling factor lookup table of 10 entries.

please note that at the moment we will not use that information within the FSW only in the processing pipeline. but the rid is forwarded with attention on board and on ground and that way it the scaling would become pseudo self containing.

@drhlxiao can you explain briefly how at the moment the 4 digit id #### is generated - it looks a bit random.

[nicHoch]

we decided to use the https://datacenter.stix.i4ds.net/api/bsd/info/startdate/enddate api endpoint to create a local file based data-store

this file could also pushed into the stix-conf repo.

the endpoint only returns metadata for an RID if the RID is published >> connected to a IOR