Device: ComputerRemoved: -### Logs or screenshotsRemoved: -Removed: -_No response_Removed: -Removed: -### ChecksRemoved: -Removed: -- ☑ I searched existing issues.Removed: -- ☑ I wrote this report in my own words, except for direct translation if needed.Removed: -
Show
[Self-Hosted] State of Media Expiry Setting Does Not Retroactively Affect Pre-Existing Media
Summary
The Media Expiry setting only affects media at the time it is uploaded. If an instance admin changes this setting, previously uploaded media is not affected and only newly uploaded media uses the updated expiry setting.
I would expect changes to this setting to also apply retroactively, such that existing media would also observe the updated expiry setting for such an event when an instance’s data storage capacity conditions change. For example, if an instance owner is running out of space, they would probably want pre-existing media to have an expiry date applied to make room; inversely if an instance owner upgraded their storage capacity, they may no longer see the need to have expiry applied for pre-existing media.
Steps to reproduce
If media expiry is already enabled:
Upload an attachment in a text chat/channel.
Go to Configuration > Instance Config > Media & retention and uncheck "Enable attachment expiry" in the admin panel.
Fully restart docker compose stack.
Go back to the attachment that was uploaded in step 1; it will still have an expiry date applied.
If media expiry is already disabled:
Upload an attachment in a text chat/channel
Go to Configuration > Instance Config > Media & retention and check "Enable attachment expiry" in the admin panel.
Fully restart docker compose stack.
Go back to the attachment that was uploaded in step 1; it will have no expiry date applied.
Environment
Version: Latest Self-Hosted as of the time of documenting this bug.
Server OS: Debian 13.5
Client Browser: Fluxer PWA in Flatpak Brave Browser
Device: Computer
Original by Rex
Show
[Self-Hosted] State of Media Expiry Setting Does Not Retroactively Affect Pre-Existing Media
Summary
The Media Expiry setting only affects media at the time it is uploaded. If an instance admin changes this setting, previously uploaded media is not affected and only newly uploaded media uses the updated expiry setting.
I would expect changes to this setting to also apply retroactively, such that existing media would also observe the updated expiry setting for such an event when an instance’s data storage capacity conditions change. For example, if an instance owner is running out of space, they would probably want pre-existing media to have an expiry date applied to make room; inversely if an instance owner upgraded their storage capacity, they may no longer see the need to have expiry applied for pre-existing media.
Steps to reproduce
If media expiry is already enabled:
Upload an attachment in a text chat/channel.
Go to Configuration > Instance Config > Media & retention and uncheck "Enable attachment expiry" in the admin panel.
Fully restart docker compose stack.
Go back to the attachment that was uploaded in step 1; it will still have an expiry date applied.
If media expiry is already disabled:
Upload an attachment in a text chat/channel
Go to Configuration > Instance Config > Media & retention and check "Enable attachment expiry" in the admin panel.
Fully restart docker compose stack.
Go back to the attachment that was uploaded in step 1; it will have no expiry date applied.
Environment
Version: Latest Self-Hosted as of the time of documenting this bug.
Server OS: Debian 13.5
Client Browser: Fluxer PWA in Flatpak Brave Browser
Device: Computer
Logs or screenshots
No response
Checks
☑ I searched existing issues.
☑ I wrote this report in my own words, except for direct translation if needed.