Currently there is an issue where the meta adapter status transitions in and out of the writing state on start, which can cause clients to trigger the detector too soon.
This changes the logic so that configuration changes are only sent down immediately if there is already a valid acquisition ID (rather than using None and then setting the acquisition ID afterward) or otherwise to just update the config cache and send that down when the new acquisition ID is set. This makes things more robust and removes the need for clients to do things in a particular order.
This is a workaround for allowing multiple acquisitions to be active at one time, so this is a problem that will go away in the future and then we won't have to do any config caching.
Currently there is an issue where the meta adapter status transitions in and out of the writing state on start, which can cause clients to trigger the detector too soon.
This changes the logic so that configuration changes are only sent down immediately if there is already a valid acquisition ID (rather than using
None
and then setting the acquisition ID afterward) or otherwise to just update the config cache and send that down when the new acquisition ID is set. This makes things more robust and removes the need for clients to do things in a particular order.This is a workaround for allowing multiple acquisitions to be active at one time, so this is a problem that will go away in the future and then we won't have to do any config caching.
Related to https://github.com/DiamondLightSource/dodal/issues/488.