Skipping audit logs against bot message deletions

[Zabuzard]

Overview

Implements and closes #393.

This adds a little check that skips writing audit log messages for message deletions against bots. Cause they generate noise that doesnt need to be reviewed and we want the channel to be noise-free. I.e. logs like this are gone now:

Details

The code changes are not trivial but quite straightforward. Unfortunately, the setup didnt allow a simple if-else, cause at the point where we know the target user, we are already in an async chain of RestAction.

I had to bubble up the target-user information one level from the more generic handleAction to the place where we have the context of MESSAGE_DELETION, i.e. handleMessageDeleteEntry. Therefore, I decided to create a little record that basically holds the User target and the MessageEmbed that handleAction used to create. I was able to enhance this further by letting the record actually generate the embed, moving the code from one place into the other.

Now that the embed and target is known at handleMessageDeleteEntry, we can check for target.isBot() and abort the computation. Unfortunately, I was not able to find any way to gracefully stop/cancel/fail a RestAction other than actually throwing (there is addCheck, but it has no hands on the value from the RestAction, so it cant be used for this) (@Tais993 any better ideas?).

I found a exception in the JDK that seems fitting for this purpose and reused it, CancellationException.

Checklist

• Implement
• Absorb this exception, it shouldnt lead to logs and noise

[Tais993]

Nope, you have the correct solution.
Another solution is to use CompletaebleFuture's, but I'm not a fan of that since they'll over-complicate the code a lot (imho)

A second note, you're throwing, this means that exception gets throw and gets logged.
We could set a default failure consumer(RestAction#setDefaultConsumer), which logs CancellationExceptions at warning instead of error.

[Zabuzard]

Nope, you have the correct solution. Another solution is to use CompletaebleFuture's, but I'm not a fan of that since they'll over-complicate the code a lot (imho)

A second note, you're throwing, this means that exception gets throw and gets logged. We could set a default failure consumer(RestAction#setDefaultConsumer), which logs CancellationExceptions at warning instead of error.

Good point. Ill have a look at that. Its unfortunately quite tricky to test this due to the audit log rate limitting. Maybe I can mock it quickly for testing it out.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication