[BUG] Event Processors mega-issue

[nafteam]

[BUG] Event Processors mega-issue

[leestarb]

I don't know whether this should be appended here or in another issue or not, but I run into an
AttributeError: 'set' object has no attribute 'append'
(coro ChannelEvents._on_raw_channel_create in file dis_snek/event_processors/channel_events.py:18)

Which version do you use? Its probably fixed in 6.0.0

[LordOfPolls]

not fixing this as it would be more useful to keep it in the cache. Bots with uncapped message caches would want to keep deleted messages, bots with TTLCaches wont care if we delete it or not

_on_raw_message_delete does not delete message from cache

[artem30801]

not fixing this as it would be more useful to keep it in the cache. Bots with uncapped message caches would want to keep deleted messages, bots with TTLCaches wont care if we delete it or not

_on_raw_message_delete does not delete message from cache

Then we should have an attribute or some other indication to convey that the message was deleted

[AstreaTSS]

not fixing this as it would be more useful to keep it in the cache. Bots with uncapped message caches would want to keep deleted messages, bots with TTLCaches wont care if we delete it or not

_on_raw_message_delete does not delete message from cache

Honestly, I'm going to disagree here. Bots with uncapped message caches might not necessarily want deleted messages, simply just wanting an easy way to have all "alive" messages for stuff (for example, a starboard bot may want every message to be kept so reaction events work faster, but having deleted messages would be a waste since they're not being reacted to).

Personally, I can't think of many cases where you would want deleted messages (for longer than the MessageDelete event), even with an uncapped cache. Sniping, I guess? They can cache that themselves for their own purposes (and I say this as someone who's made sniping stuff), hooking onto the delete event, which should be right before the message is deleted from the cache ideally. And honestly, I feel like there's more cases where we don't want a deleted message over where we do.

And even with the TTL cache, you still kinda do wanna do that since you don't want to accidentally get a deleted message. For a personal example, in one of my bots (a starboard one, I'll admit my examples are limited lol), you can specify a message ID (among other methods) to force star a message. Getting a (presumably recently) deleted message there would be awkward at the very least.

Sure, a property/attribute would be nice, but it's an extra check to something I don't see as very useful.
There's probably some very valid reason to have deleted messages in the cache that I'm missing. But even if they exist, I feel like at the very least, deleting messages from the cache should be on at default, with maybe a toggle to turn that off.

[AlbertUnruh]

I don't know whether this should be appended here or in another issue or not, but I run into an
AttributeError: 'set' object has no attribute 'append'
(coro ChannelEvents._on_raw_channel_create in file dis_snek/event_processors/channel_events.py:18)

[AlbertUnruh]

I don't know whether this should be appended here or in another issue or not, but I run into an
AttributeError: 'set' object has no attribute 'append'
(coro ChannelEvents._on_raw_channel_create in file dis_snek/event_processors/channel_events.py:18)

Which version do you use? Its probably fixed in 6.0.0

Oh, nvm, I was using v3.0.0 with Python 3.9... (I thought I was using the latest version from pip)
I'll go and upgrade to 3.10.

[LordOfPolls]

re

_on_raw_guild_ban_add, _on_raw_guild_ban_remove should update members obj, or members set in guild or something

We dont cache ban lists or ban states in guilds or member objects. Adding that functionality is out-of-scope of this issue, skipping

[LordOfPolls]

re

There are also inconsistencies and wrong typing/naming in discord event classes themselves

I cant see where this is the case, examples would be nice.