Fix: Decrement nTryes only in case of zmq timeout
1 unresolved thread
1 unresolved thread
In case if a calibration constant does not exists the function will try to retrieve it 120 times. After suggested changes the functions will try to retrieve the constant again only in case of the error: zmq.error.Again (Resource temproraly unavailable), which is raised in case of exceeded timeout.
Merge request reports
Activity
Filter activity
497 try: 498 metadata.retrieve(this_interface, 499 when=creation_time.isoformat(), 500 timeout=timeout, meta_only=meta_only) 501 break 502 except Exception as e: 503 if verbosity > 0: 504 print(e) 505 486 while ntries > 0: 487 this_interface = get_random_db_interface(cal_db_interface) 488 try: 489 metadata.retrieve(this_interface, timeout=timeout, 490 meta_only=meta_only) 491 break 492 except Exception as e: mentioned in commit 86cd4352
494 485 495 while ntries > 0: 496 this_interface = get_random_db_interface(cal_db_interface) 497 try: 498 metadata.retrieve(this_interface, 499 when=creation_time.isoformat(), 500 timeout=timeout, meta_only=meta_only) 501 break 502 except Exception as e: 503 if verbosity > 0: 504 print(e) 505 486 while ntries > 0: 487 this_interface = get_random_db_interface(cal_db_interface) 488 try: 489 metadata.retrieve(this_interface, timeout=timeout, We introduced a major bug here: the
when=creation_time.isoformat()
is essential for correctly versioned retrieval. This is why we were always getting constants in the future of the time period during report testing. Essentially we were always querying for constants closed to now.I've fixed it in the production webservice, but please one of you urgently put up a MR to address the issue!
Please register or sign in to reply