DiamondLightSource / DiamondLightSource/mx-bluesky
Think about zocalo triggering
- Dominant language
- Python
- Stars
- 4
- Forks
- 5
- Avg merge
- 1d 30m
- Merged PRs (30d)
- 2
Description
Following https://github.com/DiamondLightSource/mx-bluesky/pull/766 we should look into how we treat the zocalo callback. Previous to the linked PR we would send two messages:
1. Provide the zocalo environment and the name of the plan that should be triggering analysis
2. The plan that that then starts triggers the analysis
Following the PR we now only send message 2 and we instantiate the callback with the information from 1 (given that the environment doesn't change at runtime and the plan name only changes based on which plan you are using) but this was a bit of a hotfix. We should think about whether this is a nice architecture. One alternative is to not send the name of the plan that will be doing the triggering but instead just say that if a plan has the zocalo callback attached and a data collection is registered into ispyb then we trigger zocalo. This removes logic from the plan and makes it cleaner but ties us to the assumption that we would like to send all data collection entries to zocalo.
## Acceptance Criteria
- We have a discussion on the architecture
- Decisions are recorded
- Architecture implemented if not too large a change
Contributor guide
Assessment
This issue has not been assessed yet.