Kord Extensions•2mo ago

Production instance's caching behaving very differently

So this one is a very odd one for me. I have different parts of my code where caching works fine on my test bot (5 servers) vs my production bot (16k servers). One example is this command where I'm using guild.getMemberOrNull to display a list of users (IDs coming from my DB) into strings with their usernames. The problem is that it takes a long time to resolve the response. I would understand if it took long to resolve once, and then subsequent calls didn't, because they are supposed to be cached (EntitySupplyStrategy.cacheWithCachingRestFallback), but every time, it takes a long time. We have tried to switching strategies for this particular command, like using cache only, and it would result in a lot of users just not being found. Now, recently, I added some channel permission checks to some task I have. And I noticed that since then, the task is taking a long time to complete. Upon checking my logs, I see a bunch of requests to https://discord.com/api/v10/guilds/<guildId>/members/<myBotId>, sometimes even making two calls within the same second (there is another permission check further down the task's execution)

val botPermissions = channel.permissionsForMember(kord.selfId)

val botPermissions = channel.permissionsForMember(kord.selfId)

I try to replicate this on my test bot but no luck, not a single get member call is done. Something probably worth mentioning is that I have disabled requesting members on startup:

members {
    // We handle this manually in ChunkingExtension
    none()
}

members {
    // We handle this manually in ChunkingExtension
    none()
}

Because I implemented my own logic for this, but I have verified that it is cached locally, even running the prod token locally (with some modifications so it doesn't alter anything in prod servers), and even then, it is supposed to cache it after the first fetch.

Solution:

Fixed in Kord: https://github.com/kordlib/kord/commit/2be545a28d7e5cfa1ee2971c2612ae3e0efd334d

GitHub

Fix getMemberOrNull and getGuildMembers caching only user data (#96...

As reported in the Kord Discord server [1], these methods of StoreEntitySupplier are storing the results only to the UserData cache, not the MemberData cache, so subsequent calls would not find t...

Jump to solution

8 Replies

Galarzaa•2mo ago

Also, is this more suitable for kord support? 🤔 I might be onto something: https://canary.discord.com/channels/556525343595298817/1271484633610981493

Solution

Galarzaa•2mo ago

Fixed in Kord: https://github.com/kordlib/kord/commit/2be545a28d7e5cfa1ee2971c2612ae3e0efd334d

GitHub

Fix getMemberOrNull and getGuildMembers caching only user data (#96...

As reported in the Kord Discord server [1], these methods of StoreEntitySupplier are storing the results only to the UserData cache, not the MemberData cache, so subsequent calls would not find t...

Galarzaa•2mo ago

@gdude I'm just curious, when does the snapshot used by kordex update? On the next build? I did try to invalidate cache, use --refresh-dependencies and all, but it would still grab the version of 0.15.0-SNAPSHOT without the fix, until I manually added implementation("dev.kord:kord-core:0.15.0-SNAPSHOT")

gdude•2mo ago

I'm not entirely sure how Gradle handles it, but if you're using the KordEx gradle plugin this shouldn't be an issue Since it adds an explicit dependency on Kord Otherwise yeah I guess it updates on build But like.. I'm not pinning a specific snapshot other than 0.15.0-SNAPSHOT

Galarzaa•2mo ago

Probably resolves to some hash internally on build. Since IIRC, every snapshot, even if they have the same version, is stored as its own artifact

gdude•2mo ago

It is, but I'm not sure what actually ends up in the pom/module But yeah use the gradle plugin, it'll make stuff like this easier

Galarzaa•2mo ago

Anyway, yeah I do want to look into the kordex plugin.

gdude•2mo ago

Docs are here if needed, https://docs.kordex.dev/kordex-plugin.html

Kord Extensions Help

KordEx Plugin | Kord Extensions

Gaming

Programming

Production instance's caching behaving very differently