There is a race condition in fpgad whereby the first call to fpgad triggers the startup of dfx-mgrd, but if the first call is a dfx-mgr softener method, it's likely that dfx-mgrd will not be up in time. We should wait for comeup or otherwise report the state to the softener from the softeners thread such that we can make sure we are waiting for dfx-mgrd to start the first time, or catch the error and retry once or something.
One possible solution is to simply wait until softeners_thread.rs returns some state before activating the dbus interface for FPGAd, but this may result in timeouts and failures to start fpgad, so we should be careful.
An alternative solution is to have a way to check the softener's thread's state.
old name: tests: first test run is always dfx-mgrd dependant and it is not online on first call.
There is a race condition in fpgad whereby the first call to fpgad triggers the startup of dfx-mgrd, but if the first call is a dfx-mgr softener method, it's likely that dfx-mgrd will not be up in time. We should wait for comeup or otherwise report the state to the softener from the softeners thread such that we can make sure we are waiting for dfx-mgrd to start the first time, or catch the error and retry once or something.
One possible solution is to simply wait until softeners_thread.rs returns some state before activating the dbus interface for FPGAd, but this may result in timeouts and failures to start fpgad, so we should be careful.
An alternative solution is to have a way to check the softener's thread's state.
old name: tests: first test run is always dfx-mgrd dependant and it is not online on first call.