Open ZLLentz opened 1 week ago
I fear yet another callback queue that piles up while waiting for some EPICS connection to establish 💀
This is probably the right path though, I might just suggest we have a timeout on how long those value callbacks can dwell. When the value callback fires first, is the state unrecoverable? Or could we refresh the view and get everything working again?
Yeah, we could easily get into trouble here... In some cases this doesn't matter at all, most of the time when it matters it results in some annoying terminal spam. I'm not sure if this is ever fatal. It's pretty minor as far as I can tell.
Rather than hold up the callback queue, I'd do something like:
Expected Behavior
In all cases, the signal metadata should be communicated to the consumers of the signals prior to sending the values. This ensures the widget can prepare proper context for the data coming in.
Current Behavior
In cases where the signal is connecting for the first time after listeners have already been added, it's possible for the value callback to fire prior to the metadata callback.
Possible Solution
Add some sort of blocking/deferring mechanism, holding back all value callbacks until the first valid metadata callback is received.
Steps to Reproduce (for bugs)
EpicsSignal
with enum stringsThis may be a race condition and may not happen every time.
Context
Discovered while testing #616
Your Environment
typhos branch from the linked PR with the following critical package versions from pydm (plus my ophyd version):