Closed stevelr closed 3 years ago
I think this work is going to be similar to the work done in https://github.com/wasmCloud/wasmCloud/pull/183. We should have some way to monitor the cloudevents that we publish, which we are already doing to some extent. Then we should be able to wait for a specific event as you mentioned in your writeup.
What are the security concerns for monitoring our events @stevelr ? Is it mostly that we shouldn't be publishing sensitive information in our events, or is there another attack vector there that I'm missing?
This also depends on https://github.com/wasmCloud/wasmcloud-otp/issues/29, but if we want to port that work to be encapsulated here that's fine too.
This appears to be a duplicate of wasmCloud 83.
With my recent work on the control interface, I'm taking a stab at this with a GenServer that listens for control events. Will publish a PR once I've made some progress
As the ancient Greeks used to say, spectacules
Several of the wasmcloud tests have sleep statements to wait for the host to reach a particular state. Setting the amount of time to sleep is a trial-and-error process and either not reliable or causes the tests to take longer than necessary. There should be a way to get events from the server to know when it has reached a particular state.
Fixing this PR requires the server to emit enough events so that tests can detect when a state has been reached. Keep in mind security implications of the events; a test key may be required to allow tests to have access to the applicable events without exposing them to others in the lattice.
The goal is minimize the impact on test authors so that it's still easy to write tests. It should take one line of code, or close to it, to wait for an event. This probably needs a set of library functions that test authors can use:
wait_for_startup()
,wait_for_actor_load()
, etc. - where internally, the function subscribes to the applicable event channel with the required event filter, and waits, returning to caller.