Provide previous state in events #3272
Replies: 18 comments
-
|
This could be extended to also provide the full message payload when a message is being deleted, so that we actually can know what got deleted in the first place. This would fall in line with moderation of message edits. The current message delete format is pretty useless in terms of the information it gives you (no content, no idea who sent the message, no idea if it had embeds, no idea if it mentioned everyone (e.g. ghostpinging), no idea if it was pinned, etc). Would also link to sending the full information about an emoji when it is removed from a reaction on a message (the |
Beta Was this translation helpful? Give feedback.
-
|
Wouldn't it be easier to just say "give me every object, with all fields, all the time"? Message delete is not the only "empty" event, but it's probably the one least-likely to receive any more information because of privacy. |
Beta Was this translation helpful? Give feedback.
-
|
@SinisterRectus if only, that would make implementing a consistent interface for the entire API significantly easier and simpler... |
Beta Was this translation helpful? Give feedback.
-
|
I suggested this in one of my issues here, to implement a separate way of receiving the members on startup (if the bot has the members intent) so that it has it easier to handle member updates later on. The API as it is right now is extremely counter-productive towards a majority of existing bots, as they either have to chunk members or retrieve them when a command or similar is executed, which both takes (a lot) of time and consumes additional requests. Having Discord send the updated info through the events, or giving bots a simpler way to load stuff at startup to populate their internal caching mechanics would go a long way in improving support for them, because as of now is the API still more focused towards the Discord client and/or games and less about bots. |
Beta Was this translation helpful? Give feedback.
-
|
With yesterday's change to intents, providing previous states is a necessity. With the tools currently available, having every member in cache is necessary for many bots. Many moderation, logging, and utility bots need to know a user's previous username, nickname, avatar, etc when they get updated, and the only way to get that information is to have the old values cached. A bot that previously took a few minutes to load this cache now takes several hours, which is an unreasonable amount of downtime for a public bot. However, this is currently the only way to maintain functionality, and as such is very frustrating to deal with. |
Beta Was this translation helpful? Give feedback.
-
|
All bots with the members intent should be able to get a full member cache within 10 minutes of startup assuming ~1000 guilds/shard. There's no reason on Discord's end it should take any longer than this. |
Beta Was this translation helpful? Give feedback.
-
Sounds nice in theory, but the practice is often the exact oposite. |
Beta Was this translation helpful? Give feedback.
-
|
For some real life data, it took my bot 15 minutes successfully chunk in every guild's members from the time the final shard received a ready event. My bot's on ~120 shards right now so it's reasonably representative of the sort of timescale you might expect at the medium end of size if you do chunk every guild on startup. |
Beta Was this translation helpful? Give feedback.
-
|
To clarify a few things. The hours of time for startup are caused by the usage of old chunking features which no longer work on v6 and v8. The reason it takes so long to load is that the requests for 50 guilds will only return the members of 1 guild. The other 49 guilds then timeout and retry the request after 10 seconds (in JDA). So the time for startup can be calculated: 2500 * 10 seconds = 25000 seconds = 7 hours I have updated JDA to no longer use this old chunking even when intents are disabled. The docs need to be updated to properly represent that intents is not the requirement for these limitation but they always apply. Sending an array of snowflakes in the member chunk request doesn't work as expected and silently fails for all but the first guild. Request Guild Members should remove Edit: I've made these changes in #2178 |
Beta Was this translation helpful? Give feedback.
-
|
Assume a bot on 25 thousand servers that can see roughly 20 million unique users (approximate numbers from one of my own bots). Each chunk can contain up to 1000 users, and chunks can be requested 120 times per minute. Therefore, in the ideal case where there are no users with more than one mutual server with the bot, it would take approximately 20000000 / 1000 / 120 = 166.67 minutes to fill the cache, which is nearly 3 hours. If my math is correct, this seems unreasonably long for a bot to require just to fill its cache at startup. |
Beta Was this translation helpful? Give feedback.
-
|
@jagrosh your math is not correct tough, you can request them for up to 115 guilds per minute (to leave headroom for heartbeats), and you will get multiple chunks back per guild as needed. your need to calculate it based on servers and not member counts. also multiple shards are independant so you can requests guilds on multiple shards at the same time so to calculate the time it would be |
Beta Was this translation helpful? Give feedback.
-
|
When you request a guild's chunks, you receive all of them, not just the first 1000 |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I was incorrect, and conflating multiple problems. |
Beta Was this translation helpful? Give feedback.
-
|
Need this for |
Beta Was this translation helpful? Give feedback.
-
To my knowledge is there an event that would be triggered when the member passes the member screening, so the bot could listen for that. |
Beta Was this translation helpful? Give feedback.
-
|
it triggers a guild member update, you cannot know whether the member was previously pending without storing something though, which this request would change |
Beta Was this translation helpful? Give feedback.
-
|
According to the description of the commit that documented the pending flag, |
Beta Was this translation helpful? Give feedback.
-
|
that commit desc was incorrect, the correct info was in the screening pr and is now in the guild docs page (not live yet) |
Beta Was this translation helpful? Give feedback.
-
Description
As of late, discord has started forcing the notion of stateless bots. This however doesn't really work well when the API is literally designed to update state (the client). Currently, events only provide the new state of the updated entities. It would make it a lot easier for bots to be stateless and not require loading members if discord would provide the old state, or at least provide some way of identifying what changed.
Why This is Needed
Many moderation bots provide a way to log when messages were edited, or members updated their name/avatar. This is done to allow handling bad users which try to circumvent moderation by hiding their malicious activity before a moderator had the chance to react.
Alternatives Considered
Not being stateless. This means loading members and messages for the guilds. Very painful in the current API.
Additional Details
Due to the changes in V8, lazy loading has also been crippled by the changes to presence updates. You can no longer load member data from presence updates which means you have to use chunking or hope the user starts typing before anything happens.
Beta Was this translation helpful? Give feedback.
All reactions