i am not sure if that alreadyFlaggedUsers user thing really works.. the bot has a really long uptime usually, sometimes many months.
the way i read the code is that if a user got flagged once, they will then be immune to this check until the bot is restarted again. u could argue that its probably not an issue in practice but it smells a bit. you would need a time based cleanup for alreadyFlaggedUsers as well.

at which point u have like 30 lines of code dealing with what caffeeine gets done in one line, i guess.

private final Cache<String, Instant> userIdToAskedAtCache = Caffeine.newBuilder()
  .maximumSize(1_000)
  .expireAfterWrite(Duration.of(10, ChronoUnit.SECONDS))
  .build();

the interface is essentially that of a Map, so you have various get and put variants. internally its a LRU map, so it kicks out the entries that werent touched the longest when it reaches the max limit.

how do i make it a set ? if the cache already handles he cleanup, then storing the instant is pointless.
edit: i saw your other comment, i'll see that

caffeine only has a Map. sometimes in the past we also only needed a Set and then mapped it to something. for example to itself, i.e. key == value.

NIT: should probably be renamed into hashUtf8 for better camelCase readability

id still refactor this and move all the stuff dealing with MessageInfo into the record. so:

record MessageInfo(...) {
  static MessageInfo fromMessageEvent(MessageReceivedEvent event) {...}
}

then this addToMessageCache method becomes obsolete and can be replaced with just messageCache.add(MessageInfo.fromMessageEvent(event)); at the call-site

the hash creation would then also move into the records fromMessageEvent method (or as private static helper in the record)

I don't quite like adding a unnecessary dependencies to a record, and even less logic like how to create a hash or how to create it from an event imo.

mh... but its a factory to create instances of this record. so imo this is exactly the place it should be. what do others here think?

could u do some reordering so the flow reads top to bottom. this method would then be at the top, as entry-point. and the private methods then below it in the order they are used. the runRoutine can stay at the very bottom, i guess, since its a detached flow.

missing time unit. please add it to the name.

i dont think we need that, please remove.

the UX for it for maintainers would be really weird, having to bloat the config with 100 character long messages and whatnot. and then it didnt work bc of a smiley or other stuff that ends up slightly different.

All 4? or just the whitelist ?

sorry, the preview didnt turn out the way i wanted. i was referring to the message whitelist.

doSimilarMessageCheck should be renamed. maybe hasPostedSimilarMessageTooOften(event)

if you dont want it to start with a question-word bc of the side effects, maybe handleHasPostedSimilarMessagesTooOften(event).

but the name should clarify what the boolean it returns means and how it fits into the logic of ScamBlocker

rename to clearCache or cleanupCache or something.

rename to isOutdated or isExpired

.toLowerCase needs Locale.US