QUIT/PART has inconsistent timing of destroy_user
johnlage opened this issue · comments
QUIT destroys the user after calling the on_quit callback, while PART destroys the user first. I'm kind of assuming QUIT's behavior is correct, and PART needs to be corrected, as having access to hostname/etc while running the callback is useful in some cases.
Hm, that does indeed sound problematic. At the very least the behavior should be consistent.
Will investigate!
Looking at the relevant implementations, I don't see any specific reason why the callbacks would be invoked at different stages.
In the case of a quit, any and all users would become invalid since the bot is leaving.
In the event of a pydle-client part all users that only existed in the effected channels would become invalid as they no longer exist as far as Pydle is concerned. Since the QUIT behavior allows users to be retrieved in the downstream on_quit callback prior to destroying them, and there are no Pydle-internal references to Client.on_part, I do not see any specific reason for these callbacks to occur at a later stage than quit.
In either event, there is value in being able to retrieve the user object for the parting user. I believe I will differ to the QUIT behavior for this specific issue.
For reference, my testing was another user PART/QUITing the room the bot is in, not the bot PART/QUITing itself.
The on_part_raw event fires regardless to who it was parting, with deciding logic for discerning between the two modes.
Note the on_part and on_quit events will be called regardless of who it was that part/quit, which may be relevant to your implementation.
should be fixed in release 0.9.4