Closed dgw closed 4 years ago
dgw
commented
4 years ago @barometz Is this kind of what you were getting at when you pointed out the gender-pruning in irc_on_quit? There it makes sense to just always clear the cache, because the user is quitting (all channels; we won't see them ever unless they JOIN again). But in irc_on_part it's possible they're only leaving one common channel, and we'll still see them in another.
barometz
commented
4 years ago Not really - I guess I'm asking why gender is pruned at all. I take it that's because user tracking in general doesn't persist after a user quits? From what I'm seeing in-channel, users expect gender to persist when they reconnect, as do I. Can totally see why that doesn't mesh with Bucket's concept of user tracking though.
barometz
commented
4 years ago OK, should've reported this better. People have been seeing the gender info getting reset at unpredictable intervals, but maybe I misunderstood the source.
dgw
commented
4 years ago If gender is getting lost between quit and reconnect, that's a bug somewhere else. But if you're getting reports that gender info seems to be "reset" unpredictably, that's probably #92. (tl;dr for that: join as nick1, set gender, /nick nick2, quit, then rejoin as nick1: poof, Bucket has "forgotten" nick1's gender because the database was updated with the new name on /nick.)
When a user joins, we load their set gender from the DB if it's not cached:
When someone's gender preference is set, it's immediately stored in the cache and persisted to the database:
dgw
commented
4 years ago Regardless of what you were originally trying to report, I'm glad it prompted me to look at the PART/KICK logic again, because those were wrong/incomplete, respectively.
On PART, prune the user's cached gender only if Bucket no longer shares any channels with them.
KICK did not prune the gender cache at all before, but it now follows the same (new) logic as PART.