DELETE /guilds/{guild.id}/roles/{role.id} takes a very long time on larger guilds (even with no members in the role)

[QuantumToasted]

I just discovered this testing a bot out, and I'm not sure why, but trying to delete a role on a larger guild (mine has 35,000+ members for example) makes this endpoint take 4-5 seconds or more to complete, even if the role has no members at all. Compared to a smaller guild where it takes 200ms or less. Is this a bug or a unfortunate side-effect of deleting roles for larger guilds? I assume it's just that no matter the number of members a role has it has to check EVERY member for the role or something before deleting it.

[Taarek]

My guess it's because GUILD_ROLE_DELETE needs to be dispatched to so many users, there is a short delay.

[night]

It's because we iterate over the entire member list to remove the role. It can't be made faster without making it async table scan.

[erkinalp]

Hmm, did you consider adding a disabled property to role objects? Then you can disable the role first and perform actual deletion async.

[noocoke]

that is so real

[QuantumToasted]

Alright, I just wasn't sure what the cause was. It'd be a nice room for a performance improvement since i'm sure it takes even longer in larger guilds than the ones I'm in.

[Skye-31]

I'm not entirely sure if this is possible, but it could be handy to delete the role first, and then remove it from the members afterwards. If possible, this could be used to prevent logging bots sending many messages along the lines of "Deleted role was removed from x". Currently the only method is to delay the log for a few seconds and see if the role has been deleted then - but the for large servers this clearly doesn't work because of the big delay.

[kyranet]

I'm not entirely sure if this is possible, but it could be handy to delete the role first, and then remove it from the members afterwards. If possible, this could be used to prevent logging bots sending many messages along the lines of "Deleted role was removed from x". Currently the only method is to delay the log for a few seconds and see if the role has been deleted then - but the for large servers this clearly doesn't work because of the big delay.

The current order is better imo, it ensures the dependencies are taken down before the entry itself. Same happens with foreign keys in relational databases, by default you can't take them down without taking down the entries that depend on it, in this case, a "role" id that is referenced by many "member roles".

Besides, this behaviour is consistent with everything else in the API, no need to make this a special case.

[Skye-31]

That's a good point. How about dispatching the role delete event in the gateway first, however?

[kyranet]

That would cause certain problems in both Discord's side (event retention and delays, which increases memory usage) and clients (specially moderation bots) as they'll remove a role they cannot reference and will have no idea what role was deleted, requiring them to cache a deleted entry in memory temporarily and "watch for members to change", which is more troublesome than the current system.

[Skye-31]

Perhaps a better alternative would be something like #1715, where a bulk guild member role remove event is sent. This could just be one single payload that includes all of the member ids where the roles were removed. This would be significantly lighter work on the gateway, as it would only send one event to each online member, instead of an event for every member that had their role removed.

In fact this could apply to more than just role removes. Anything where it affects multiple items:

• A voice channel being deleted (bulk voice state update, instead of 1 for every member)
• A guild member prune (like purge events #1715)
• A role being deleted, like this very issue

I'm aware a lot of these changes would be breaking, so perhaps they could be included in the v8 gateway, which night mentioned here, as that was mentioned to include a lot of breaking changes.