Skipping audit logs against bot message deletions #395
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 ofRestAction
.I had to bubble up the target-user information one level from the more generic
handleAction
to the place where we have the context ofMESSAGE_DELETION
, i.e.handleMessageDeleteEntry
. Therefore, I decided to create a little record that basically holds theUser target
and theMessageEmbed
thathandleAction
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 fortarget.isBot()
and abort the computation. Unfortunately, I was not able to find any way to gracefully stop/cancel/fail aRestAction
other than actually throwing (there isaddCheck
, but it has no hands on the value from theRestAction
, 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