I agree this is not ideal, but I'm wondering, how would we know whether the user is vanished, especially when doing the mass reassignment process?

We can expand T351234: Mentorship: Remove blocked users from Mentorship to locks and drop mentorship for locked users, but "user gets vanished" and "user gets locked" are two overlapping but separate events. For example, if we go this way, we would be:

• dropping the relationship whenever they are locked as compromised (which is by nature, temporary, and locks do not have an expiry associated with them),
• NOT dropping the relationship whenever they are vanished manually (using a process different than Special:GlobalVanishRequest), as the only way to get the vanishing lock to appear

We can also consider global blocks (where we can check expiry, similar to blocks), but that does not cover vanishes at all.

We can also add a "onGlobalUserVanishingComplete" hook (similar to onRenameUserComplete), but this would only work for new vanishes, not vanishes that happened over a year ago (which is what happened in this case).

Do you have any thoughts on what would be the ideal action here, @Pppery?

For the record, we already received some negative feedback about dropping the relationship on indefinite blocks (T392280), and locks are applied in even broader set of situations. So, I'm not convinced checking for locks here is the correct approach.

The other option is to, when the mentor of a blocked or locked user is removed from mentorship, to silently drop the relationship at the time of reassignment, not at the time of the block or lock.

In T400738#11110980, @Pppery wrote:

The other option is to, when the mentor of a blocked or locked user is removed from mentorship, to silently drop the relationship at the time of reassignment, not at the time of the block or lock.

That's true. This would have the disadvantage of looking non-deterministic at places like Special:MentorDashboard, but we can certainly do that.

I initially assumed that this would be a very rare occurrence, but apparently that is not the case. I'm thankful to @Urbanecm_WMF for helping me understand that getting vanished is effectively self-service now on at least one of the Apps?

In that case, having that event being explicitly represented in our domain, e.g. as suggested by a hook like onGlobalUserVanishingComplete in core, makes a lot of sense to me.

Though reading https://meta.wikimedia.org/wiki/Global_locks, it seems that (global) locks are only applied for very severe cases. What would be a scenario where we would want to keep an account as a mentor or mentee after they have been locked?

In T400738#11116231, @Michael wrote:

I initially assumed that this would be a very rare occurrence, but apparently that is not the case. I'm thankful to @Urbanecm_WMF for helping me understand that getting vanished is effectively self-service now on at least one of the Apps?

Requests are now possible via both our apps and via http://meta.wikimedia.org/wiki/Special:GlobalVanishRequest. Vanishing is completely self-serve for certain users, for others, the vanishing requests needs to be approved by a Steward or a Global Renamer (that's the vanishing queue I referred to in the meeting).

If you wish to get a better idea about the frequency, see https://meta.wikimedia.org/wiki/Special:Log/globalauth/AccountVanishRequests. This log page shows automated post-vanishing account locks, which happen whenever an account is vanished (regardless of whether it is a fully automated vanishing or a human-reviewed vanishing).

In any case, vanishings are relatively common (hundreds of cases a month). It's more of a coincidence that we didn't receive a similar report before.