Counterintuitive behaviour while using WatchedCustomServices

[eshaanganesh2]

Whenever we encounter any method, class, or package listed in WatchedCustomServices and it satsifies the level criteria, an assault is launched.

However, it's important to note that the level count increases each time we encounter a watched method, class, or package, regardless of whether it's present in the WatchedCustomServices list or not.

To simplify this, I propose that we only increase the level count while encountering any watched method (or class or package) listed in WatchedCustomServices. This adjustment would make the behavior more intuitive and ensure that the level count reflects the actual monitoring of the specified elements within the WatchedCustomServices list.

This can be better illustrated through an example.

Current Behavior

Consider the below code which consists of a service layer implementation invoking 3 functions (which are defined in another class annotated with @Component )

class serviceImpl(){ 

    @Autowired
    DemoApplicationComponent x;

    x.func1();
    x.func2();
    x.func3();
}

Let us assume the below configuration property has been set for WatchedCustomServices
chaos.monkey.assaults.watchedCustomServices=com.example.demo.component.DemoApplicationComponent.func2

and the watcher property for Component has been set to true
chaos.monkey.watcher.component=true

Let us also assume that a level count of 4 was set for this example
chaos.monkey.assaults.level=4
chaos.monkey.assaults.deterministic=true

When the request arrives at the serviceImpl class, the level count increases as follows:

x.func1(); // level = 1 (Not present in WatchedCustomServices)
x.func2(); // level = 2 (Present in WatchedCustomServices) ; 2%4!=0, therefore no assault is launched
x.func3(); // level = 3 (Not present in WatchedCustomServices)

Upon making a 2nd request to the serviceImpl class, the values change as follows:

x.func1(); // level = 4 (Not present in WatchedCustomServices)
x.func2(); // level = 5 (Present in WatchedCustomServices) ; 5%4!=0, therefore no assault is launched
x.func3(); // level = 6 (Not present in WatchedCustomServices)

Upon making a 3rd request to the serviceImpl class, the values change as follows:

x.func1(); // level = 7 (Not present in WatchedCustomServices)
x.func2(); // level = 8 (Present in WatchedCustomServices) ; 8%4==0, therefore assault is launched!
x.func3(); // level = 9 (Not present in WatchedCustomServices)

So, what we notice is that the assault occurs while handling the 3rd request, which is unexpected.

Expected Behavior

The expected behavior would be for the assault to happen during the handling of the 4th request. We'd anticipate the level count to increase by 1 each time func2() is encountered, hence triggering the assault in the 4th request.

An additional note (if required) may be included in the documentation explaining that the level count will only increase if the method specified in the WatchedCustomServices list is encountered. In case an incorrect value is assigned to the WatchedCustomServices property, no level count increment would be observed and hence, no assault would be initiated. Therefore, it is imperative to exercise caution when setting values within the WatchedCustomServices list.

[eshaanganesh2]

A PR with the proposed changes has been raised at #452