Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean reset of applet state when scan is overwritten #387

Open
dnadlinger opened this issue Apr 10, 2024 · 0 comments · May be fixed by #395
Open

Clean reset of applet state when scan is overwritten #387

dnadlinger opened this issue Apr 10, 2024 · 0 comments · May be fixed by #395
Assignees
Labels
A-applet Involves the ndscan plot applets C-bug This is a bug in existing functionality

Comments

@dnadlinger
Copy link
Member

Especially with servos that manually use TopLevelRunner, it is quite common for another experiment to start publishing a scan to the same dataset prefix as a previous completed scan. The applet should handle this cleanly and never show state with information from both runs mixed together.

See discussion in #381, where at least the source_id display was fixed, but which wasn't complete.

Not sure what the best marker of a new scan would be; perhaps something like ndscan_schema_revision. Separating things like that cleanly was a large part of my initial motivation for the server-side dataset namespacing. Without it, we might need to manually handle this in the subscriber code (such that the old data isn't used to get the schemata/points immediately after the refresh).

Another option would be to give up and accept that there might sometimes be mixed states. If the user explicitly specifies the same top-level runner dataset root from multiple experiments (can be multiple instances of the same experiment), there is nothing we can do to avoid the mess on the applet side anyway.

Does sipyco emits mods when datasets are set_dataset() from a new experiment, even if the value has not changed?

Then a clean solution would be to designate one dataset that takes the role of begininng a new scan (e.g. ndscan_schema_revision), and when this is observed in the subscriber code, chuck away all the current datasets and append the new datasets in only as they come in.

(The problem to avoid here is to avoid refreshing the scan after a new one has begun, but immediately load in all the new data that might still be present.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-applet Involves the ndscan plot applets C-bug This is a bug in existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants