#1894 MUC rooms are not deleted after tombstone expiry
Reporter
lissine
Owner
Nobody
Created
Updated
Stars
★ (1)
Tags
Priority-Medium
Type-Defect
Status-Invalid
lissine
on
Steps to reproduce:
- Set `muc_tombstone_expiry` to a low value for easier testing e.g. 120 seconds
- Reload the config and mod_muc
- Run `muc:list("conference.example.org")` to note the number of rooms on the muc component
- Destroy a room
- Wait for the tombstone_expiry period to finish e.g. 120 seconds
- Run `muc:list("conference.example.org")` again.
The number of rooms will be unchanged, and the destroyed room is still listed.
In fact, the destroyed room can also be seen in `Service Discovery` using a client like Gajim.
For instance, I have rooms that I destroyed months ago, that still show up in the shell and in Service Discovery, and their reported number of participants is zero.
Note: there is no cron task that deletes rooms with expired tombstones.
The only cron task that I have on conference.example.org is "Remove expired messages"
This issue was observed in prosody 0.12 and prosody 13.0
Zash
on
Thanks for the report.
This is working as intended. Tombstones remain until someone tries to create the same room after the expiry. There is no automated removal.
This could perhaps be reconsidered at a later point since we have mod_cron now, which didn't exist when this was implemented.
It has been argued that tombstones should not expire at all, since some clients do not stop trying to join and allowing them to be recreated at all may leak the JID of users who were joined before destruction.
muc:room(jid):destroy() a second time can be used to destroy the tombstone
Changes
tags Status-Invalid
lissine
on
Is it expected for destroyed rooms that have a tombstone to show up in MUC Service Discovery?
Zash
on
No, disco#items should not contain destroyed rooms. Want to file an issue about that?
Showing up in muc:list() is awkward but expected given that tombstones are implemented as locked rooms, we could tweak the presentation or hide them.
lissine
on
Hmm, if tombstones are supposed to remain forever, then what's the point of `muc_tombstone_expiry` (which is set to 31 days by default) ?
Zash
on
I don't remember. 31 days must have seemed like a very long time in 2018, long enough for clients to give up trying to join, or possibly a compromise between 'forever' and users who don't like it if there's "deleted" data left around. #1182 doesn't have any rationale, nor the commit message unfortunately.
Steps to reproduce: - Set `muc_tombstone_expiry` to a low value for easier testing e.g. 120 seconds - Reload the config and mod_muc - Run `muc:list("conference.example.org")` to note the number of rooms on the muc component - Destroy a room - Wait for the tombstone_expiry period to finish e.g. 120 seconds - Run `muc:list("conference.example.org")` again. The number of rooms will be unchanged, and the destroyed room is still listed. In fact, the destroyed room can also be seen in `Service Discovery` using a client like Gajim. For instance, I have rooms that I destroyed months ago, that still show up in the shell and in Service Discovery, and their reported number of participants is zero. Note: there is no cron task that deletes rooms with expired tombstones. The only cron task that I have on conference.example.org is "Remove expired messages" This issue was observed in prosody 0.12 and prosody 13.0
Thanks for the report. This is working as intended. Tombstones remain until someone tries to create the same room after the expiry. There is no automated removal. This could perhaps be reconsidered at a later point since we have mod_cron now, which didn't exist when this was implemented. It has been argued that tombstones should not expire at all, since some clients do not stop trying to join and allowing them to be recreated at all may leak the JID of users who were joined before destruction. muc:room(jid):destroy() a second time can be used to destroy the tombstone
ChangesIs it expected for destroyed rooms that have a tombstone to show up in MUC Service Discovery?
No, disco#items should not contain destroyed rooms. Want to file an issue about that? Showing up in muc:list() is awkward but expected given that tombstones are implemented as locked rooms, we could tweak the presentation or hide them.
Hmm, if tombstones are supposed to remain forever, then what's the point of `muc_tombstone_expiry` (which is set to 31 days by default) ?
I don't remember. 31 days must have seemed like a very long time in 2018, long enough for clients to give up trying to join, or possibly a compromise between 'forever' and users who don't like it if there's "deleted" data left around. #1182 doesn't have any rationale, nor the commit message unfortunately.