Can't start after a crash if previously queued shots have been deleted

[philipstarkey]

Original report (archived issue) by Shaun Johnstone (Bitbucket: shaunj, GitHub: shjohnst).

---

If BLACS crashes, and hence doesn't save the latest experiment queue, the next time it starts it tries to load a potentially outdated queue from the last time it was closed cleanly.
There should be a try/except when loading these shots into the queue on startup, as they may have been deleted since the configuration was last saved.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

Do you have a traceback for this?

As far as I can see the queue should already ignore shots that aren't accessible. I can see that loading an outdated queue would result in "repeat shots" being generated for any shots that have been run, but that seems distinct from the bug you've reported.

A better fix would probably be to regularly save the BLACS state (say after each shot has been executed) by duplicating this line into the QueueManager.manage method (probably at the same place we save the front panel data into the current shot. The downside to this is that the BLACS HDF5 file will probably grow in size very rapidly because HDF5 is very bad at releasing space from deleted elements. That's something that we should be solving globally anyway, but could delay the "proper" fix to this issue.

[philipstarkey]

Original comment by Shaun Johnstone (Bitbucket: shaunj, GitHub: shjohnst).

---

Sorry, it was in Seb's lab and I was busy, so got him to go and "fix" it by
just moving/renaming a shot file to the location that BLACS was looking for
(apparently once he did that for the first file BLACS would load, despite
further popups about subsequent shots trying to be loaded into the queue
that he could dismiss).
I'll try to reproduce the issue when I get a chance.