potentialy a wrong message type usage
- A few places use
messages.DeviceStatusMessage
forMessageEndpoints.device_progress
endpoint:
- https://gitlab.psi.ch/bec/bec/-/blob/master/device_server/device_server/devices/devicemanager.py#L365-371
- https://gitlab.psi.ch/bec/bec/-/blob/master/scan_server/scan_server/scan_stubs.py#L212-215
while in other it's messages.ProgressMessage
, e.g.
- https://gitlab.psi.ch/bec/bec/-/blob/master/device_server/device_server/devices/devicemanager.py#L376-382
- https://gitlab.psi.ch/bec/bec/-/blob/master/bec_client/bec_client/callbacks/scan_progress.py#L30-35
Probably, the first ones should be corrected. Anyways, it doesn't seem like a good idea to mix multiple message types in a single endpoint.
- (copied from the comment below) There is one other suspicious place:
-
https://gitlab.psi.ch/bec/bec/-/blob/master/device_server/device_server/device_server.py#L295-311 The same
messages.DeviceReqStatusMessage
is pushed toMessageEndpoints.device_req_status(device_name)
as a redis string, andMessageEndpoints.device_req_status(status.instruction.metadata["RID"])
as a redis list. Feels like, those should be different endpoints, as in the latter it's RID and not device name.
- A reference to a non-existent
MessageEndpoints.scan_status() + "_list"
endpoint: https://gitlab.psi.ch/bec/bec/-/blob/master/scan_bundler/scan_bundler/scan_bundler.py#L272-278 Probably, a remnant after some refactoring happened in the past.
Edited by usov_i