Retrying to set beamline parameter after abort breaks the app

[axelboc]

I noticed this while working on #1432 (i.e. it was broken before) with the mock beamline environment.

The full error displayed as beamline attribute message in the UI: Exception 1 validation error for FloatValueModel value value is not a valid float (type=type_error.float)

The full back-end stacktrace is too long to paste here.

The only way to recover is to restart the server. Otherwise, here is what the app looks like if I reload the page:

[walesch-yan]

I tried to recreate this issue and I could only detect it for the Energy and Transmission (for Transmission it happened once in many attempts). Could you confirm this or have you seen it on the other parameters as well? For Wavelength and Resolution I could observe other (maybe related) issues (see #1436 and mxcube/mxcubecore#1037)

[axelboc]

Indeed, I confirm your observations. Only Detector works as expected.

[axelboc]

Other issues:

1. The real limits for Wavelength don't seem to match those in the log message:

2. The Resolution log message says "Invalid value" without providing limits

[walesch-yan]

I agree that the log message could be improved in this case. These are slightly modified errors, we get from mxcubecore.

For the first issue: This is the value we would set Energy to, when we modify Wavelength. My understanding is that Wavelength has no limits, instead we check if the supposed Energy value is acceptable and the event called from this is the one that returns the error

[walesch-yan]

It seems that the initial issue came from a GreenletExit exception that was not correctly handled. I made a fix for this in mxcubecore (see mxcube/mxcubecore#1038) which has been merged.

Unfortunately the issues regarding the log message need a little bit more of investigation. I propose to open a new issue for them and close this one?

[beteva]

Maybe few explanation how and why energy, wavelength, resolution and detector distance "motors" are connected

1. The Detector (detector distance) is a MotorMockup motor. In the real life it is a real motor. When moving, the HO sends the updateValue signal and the adapter gets it. This is why the detector distance always works fine when you try to abort the movement.
2. The energy is a calculation motor. It is not the case of the mock motor, but in the real live it could also be a whole set of actions (not just moving the motor) so abort not only stops a motor movement, but also should stop a sequence.
3. wavelength is a motor, calculated from the energy. It does not have the get_value and get_limits methods, but get_wavelength and get_wavelength_limits, but all this is handled by the adapters. When you move the motor, it actually moves the energy motor.
4. The EnergyMockup sets the Energy limits to 4,20, Than the wavelength limits are calculated from this value, so there should be wavelength limits, Need to investigate why what we see are the energy limits, instead of the wavelength ones.
5. The resolution is a calculation motor. It is a function of the energy, the detector distance and the detector radius. The detector radius itself is a function of the detector distance, so it is a vicious circle when you calculate the distance from the resolution. When we change the energy, we recalculate the resolution and its limits. When we move the detector the resolution is recalculated as well, but the limits do not change. When we move the resolution, it is actually the detector distance motor which moves. Because of the nature of the calculations, depending on how big is the difference in the movement, the calculations might be not precise enough, so we move twice - once to get close to the desired resolution and one more time to be sure that we are at the desired resolution.

I will have a deeper look on the EnergyMockup and the energy and resolution adapters.

[marcus-oscarsson]

@walesch-yan Did you also have a chance to look if the limits of the energy mockup change to something other than Tuple[float, float] ? That is why one would get Exception 1 validation error for FloatValueModel value value is not a valid float (type=type_error.float. Or was that because of the actual value being a GreenletExit perhaps :) ?

[walesch-yan]

@marcus-oscarsson From my observations, we got this because the actual value was a GreenletExit. After handling this specific case, I did not get this error message anymore

[marcus-oscarsson]

Ok, thanks for the update