Do we need a synchronization mechanism?

[Lawouach]

Right now, the only way to give room for a process to happen is to use a pause before/after. This is obviously fine for fairly simple scenarios, but sometimes this is not enough.

So, do we need a more evolved synchronization mechanism?

I can see the benefit but it feels like a slippery slope because that means the toolkit becomes a state machine and increases in complexity. At first sight, I'm scared of that.

But I need the input from the community to make a better judgement.

[valeriap]

@Lawouach
In order to give the system enough time for recovering after an error injection before validating again the steady state hypothesis, the only way is to specify a pause after the last method.
What about adding the possibility for steady state hypothesis or for its probes to match the tolerance within a specified amount of time?
This would make the tests faster.
And in case the tolerance would be allowed also in probes used as methods, this approach would also provide some sort of synchronization.

[Lawouach]

I think there are various discussions around the same subject indeed.

When we started the chaostoolkit, we were very much on the idea you are exploring, not testing. But we also acknowledge now that once you have explored, you want to run continuously with a tester mindset.

The current spec has limits herein that regards. I think we need to start considering a testing mode where, indeed, you look for more control when to bail from the experiment. For instance, others have reported wanting to bail from the method itself by using tolerance there too.

I'm thinking this needs to be addressed before 1.0 because it would be lacking otherwise. I'll come up with a proposal this week.

[github-actions]

This Issue has not been active in 365 days. To re-activate this Issue, remove the Stale label or comment on it. If not re-activated, this Issue will be closed in 7 days.

[github-actions]

This Issue was closed because it was not reactivated after 7 days of being marked Stale.