A possible fix would be to never store the channel shape upon startup. Only give the channel shape when the object is asked to describe itself and pull straight from the yaq_client. It's not clear if this would have negative consequences, however.
A current workaround is to restart the qserver environment with the desired channel shape of the sensor reflected at the yaq daemon level.
This creates a problem when the channel shape is dynamic, e.g. when changing the region of interest on a camera from scan to scan.
In https://github.com/bluesky/yaqc-bluesky/blob/master/yaqc_bluesky/_is_sensor.py, the problem arises from line 18 where the IsSensor object describes its shape to bluesky. It pulls from where the channel shapes are stored upon daemon startup in line 12.
A possible fix would be to never store the channel shape upon startup. Only give the channel shape when the object is asked to describe itself and pull straight from the yaq_client. It's not clear if this would have negative consequences, however.
A current workaround is to restart the qserver environment with the desired channel shape of the sensor reflected at the yaq daemon level.