user_parter removes other users from room when deactivation endpoint is called

[matrixbot]

This issue has been migrated from #16582.

---

Description

Whenever I call the deactivate (+erase) endpoint on synapse (this case for userA) it kept removing another user (userB) from all rooms.
Today this happened for a second user (userC). The notable difference here is that userB had left one of the rooms on their own. C hasn't so far.

Steps to reproduce

• Deactivate+Erase userA
• Watch public rooms
• See userA unsetting their display name and leaving
• See userB and userC leaving all public rooms they were in

Homeserver

Selfhostes

Synapse Version

1.94.0

Installation Method

Docker (matrixdotorg/synapse)

Database

single postgres server, no restore from backup

Workers

Single process

Platform

Debian 11 with docker

Configuration

Presence and retention are enabled in the affected public rooms.
The public rooms have a 48h retention policy for about 1.5 years.

The homeserver does not federate.

Relevant log output

2023-10-31 09:18:04,843 - synapse.handlers.deactivate_account - 158 - INFO - POST-911131 - Marking @userA:myhomeserver as erased
2023-10-31 09:18:04,845 - synapse.federation.sender - 592 - INFO - process_event_queue_for_federation-1377 - Unexpectedly did not have cached prev group for $oxitnVVee-cjwUyKUZgPf1iHCbQ0kYYvXbov3uoZXyU
2023-10-31 09:18:04,853 - synapse.handlers.deactivate_account - 234 - INFO - user_parter_loop-5 - Starting user parter
2023-10-31 09:18:04,861 - synapse.handlers.deactivate_account - 240 - INFO - user_parter_loop-5 - User parter parting '@userB:myhomeserver'
2023-10-31 09:18:04,873 - synapse.handlers.deactivate_account - 254 - INFO - user_parter_loop-5 - User parter parting '@userB:myhomeserver' from '!wmwqhJvBlcVtlMzYXp:myhomeserver'
2023-10-31 09:18:05,119 - synapse.handlers.deactivate_account - 254 - INFO - user_parter_loop-5 - User parter parting '@userB:myhomeserver' from '!WCxYbgOzUJowbPisiS:myhomeserver'
2023-10-31 09:18:05,127 - synapse.federation.sender - 592 - INFO - process_event_queue_for_federation-1378 - Unexpectedly did not have cached prev group for $S4RKH353eV6CNCxkP3aVVVreIu6qLYmuqZEhwV9fhDE
2023-10-31 09:18:05,338 - synapse.handlers.deactivate_account - 243 - INFO - user_parter_loop-5 - User parter finished parting '@userB:myhomeserver'
2023-10-31 09:18:05,339 - synapse.federation.sender - 592 - INFO - process_event_queue_for_federation-1379 - Unexpectedly did not have cached prev group for $mJL1JXe8swj8vFf0MZLdXvwx4UZxRf1YyAw1Q42L-yw
2023-10-31 09:18:05,343 - synapse.handlers.deactivate_account - 240 - INFO - user_parter_loop-5 - User parter parting '@userC:myhomeserver'
2023-10-31 09:18:05,352 - synapse.handlers.deactivate_account - 254 - INFO - user_parter_loop-5 - User parter parting '@userC:myhomeserver' from '!wmwqhJvBlcVtlMzYXp:myhomeserver'
2023-10-31 09:18:05,553 - synapse.handlers.deactivate_account - 254 - INFO - user_parter_loop-5 - User parter parting '@userC:myhomeserver' from '!WfkDZztWcIEzOOmRNW:myhomeserver'

Anything else that would be useful to know?

No response

[ThoreKr]

This appears to still be an issue, where a user requests deactivation, but the user_parter never runs.

This happened again last week, where a user had requested deactivation on the 16th, but then logged in again and actively used the account.
On the 23rd our cleanup script called the deactivate (+erase) endpoint again to remove accounts that have been deleted in the IdP and the user_parter began to work, parting that user from all rooms.

Again, when checking the userinfo endpoint, the account returns deactivated: false.

I don't fully understand why the user parter doesn't clean up its jobs for almost 2 weeks. Is this a configuration issue?

Would it make sense to check the deactivation status again, before proceeding to part the user from all rooms?

[reivilibre]

Likely root cause is that the user_parter loop didn't finish kicking the user out of the rooms (maybe due to a server restart or something else, would need more time to look into it).
The user then stays in users_pending_deactivation, which is the queue for the user_parter.

If that user is reactivated, their entry is not removed from the users_pending_deactivation table. (This is likely the crux of this bug.)

When another deactivated, it re-triggers the processing of this queue, which still contains the first user.