Random seed value each time get_random_db_interface is executed

@klackova reported an issue for having a report with multiple warnings that constants were previously injected.

These Warnings state that constants were injected previously and will not be injected again. After checking CALCAT it is observed that the mentioned constants were injected during the same processing with the Warnings.

https://in.xfel.eu/calibration/reports/2464 https://in.xfel.eu/calibration/reports/2473 https://in.xfel.eu/calibration/reports/2472

Description

From the calibrationDBRemote and debugging cal_tools.

• I found that the constants with the Warnings were attempted to be injected two times. First time there was a zmq.error of Resource temporarily unavailable. I assume this error was on the reply side after receiving the injection request and injecting the constant then sending back to pycalibration at https://git.xfel.eu/karaboDevices/calibrationDBRemote/-/blob/master/src/calibrationDBRemote/calibration_db_remote.py#L422 that injection was successful.

• I also observed that even though we are using multiprocessing and trying to use random interface between tcp://max-exfl016:8015 and tcp://max-exfl016:8045 the SlopessFF for all 16 modules are being injected using the same interface and the same for BadPixelsFF constants. This is the reason for using the same seed value.

Initializing the random generator using a random seed value. Solved this issue.

As the issue was pretty reproducible during testing with max-exfl017. I could make sure that the issue disappeared with the fix.

How Has This Been Tested?

Tested by running the SUMMARY FF notebook with one of the mentioned FF processings but while injecting to max-exfl017 and saving no local constants.

Relevant Documents (optional)

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

Reviewers

@schmidtp @klackova @danilevc

Wow, nice find. Definitely makes sense to seed the generator to not always pick the same one.

Indeed zmq would throw an EAGAIN when trying to send/receive a message in the wrong state of an asynchronous socket (as is the case with REQ/REP in calibrationDBRemote). I don't fully understand yet however why each constant is attempted to be injected twice?

added 1 commit

• 0e7cc8d4 - remove unneeded args from np.random.seed

Compare with previous version

resolved all threads

Thanks, LGTM!

Thank you for the review!

merged

mentioned in commit 517b8958

changed milestone to %3.7.1