Ivan Abarca

As a workaround, I think you could try replacing the `RequestQueueFactory` with a Processor legacy one, or a Sinks-based one using `timeoutError` strategy or larger buffer

I was able to reproduce with offline members

Scratch that, any guild without member requesting will be affected (all non-large ones by default) Considering if we should just warn+suggest explicit requests, or change the behavior, although this can...

Workaround for now: use MemberRequestFilter to all, or a different one you can customize. ```java DiscordClient.create(System.getenv("token")) .gateway() .setMemberRequestFilter(MemberRequestFilter.all()) .setEnabledIntents(IntentSet.of( Intent.GUILD_MEMBERS, Intent.GUILDS, Intent.GUILD_MESSAGES, Intent.GUILD_MESSAGE_REACTIONS, Intent.DIRECT_MESSAGES, Intent.DIRECT_MESSAGE_REACTIONS)) .withGateway(gateway -> gateway.on(MemberUpdateEvent.class, event ->...

Yes, if your bot belongs to many small guilds, as 1 member list request is sent per guild. You could hit a rate limit and get successive members at a...

I think you could explore delegating our default `DispatchEventMapper` to inject custom capabilities and you can derive extended versions of `Event` holding the data from it. I might add a...

Let's see if our current API can work with this. Besides trying the custom mapper implementation, we have our Store API that could use some improvements for the Redis implementation...

Nice, let us know if it's good because we're currently discussing with @danthonywalker potential improvements to how we layout our data in redis. Regarding the mapper impl, I'll add a...

Follow up on this issue: while the current API makes it possible, it involves quite a long process of creating a custom DispatchEventMapper class and also producing an alternative Event...

Scheduling this for next 3.1, there are other use cases where this would be useful, like working with a noop cache and the current workaround (accessing raw dispatch flux) is...