Previously, ASCIICAST_GC_DAYS variable was used to control max age of unclaimed recordings, after which they were soft-deleted, i.e. marked as "archived" (confusing term), effectively making them inaccessible by de-listing them and showing 410 Gone page for direct recording links.
This PR implements 2-step deletion process. It introduces new config variable, UNCLAIMED_RECORDING_TTL, which controls the behaviour of automatic removal of unclaimed recordings.
Step 1 is soft-deletion, which is what we had previously. Also, we now use term "deletion" instead of "archival", because "archival" confused people, making them think the recordings are put in some sort of archive, while in fact they were just hidden and waiting for proper deletion.
Step 2 is hard-deletion, which removes any traces of a recording from the system (deleting DB records + recording file).
UNCLAIMED_RECORDING_TTL accepts TTL values in days, in the following formats:
UNCLAIMED_RECORDING_TTL=7 - soft-deletion after 7 days, no hard-deletion
UNCLAIMED_RECORDING_TTL=7,30 - soft-deletion after 7 days, hard-deletion after 30 days
UNCLAIMED_RECORDING_TTL=7,7 - hard-deletion after 7 days (soft-deletion would be the same therefore doesn't apply)
when UNCLAIMED_RECORDING_TTL is not set - no auto-deletion whatsoever
The benefit of having 2-step auto-deletion process like this, especially for a main asciinema server instance - asciinema.org - is to give people time to reach out to the server admin until it's too late to recover the recording.
On asciinema.org we used ASCIICAST_GC_DAYS=7 and I plan to replace it with something like UNCLAIMED_RECORDING_TTL=7,90.
Previously,
ASCIICAST_GC_DAYSvariable was used to control max age of unclaimed recordings, after which they were soft-deleted, i.e. marked as "archived" (confusing term), effectively making them inaccessible by de-listing them and showing 410 Gone page for direct recording links.This PR implements 2-step deletion process. It introduces new config variable,
UNCLAIMED_RECORDING_TTL, which controls the behaviour of automatic removal of unclaimed recordings.Step 1 is soft-deletion, which is what we had previously. Also, we now use term "deletion" instead of "archival", because "archival" confused people, making them think the recordings are put in some sort of archive, while in fact they were just hidden and waiting for proper deletion.
Step 2 is hard-deletion, which removes any traces of a recording from the system (deleting DB records + recording file).
UNCLAIMED_RECORDING_TTLaccepts TTL values in days, in the following formats:UNCLAIMED_RECORDING_TTL=7- soft-deletion after 7 days, no hard-deletionUNCLAIMED_RECORDING_TTL=7,30- soft-deletion after 7 days, hard-deletion after 30 daysUNCLAIMED_RECORDING_TTL=7,7- hard-deletion after 7 days (soft-deletion would be the same therefore doesn't apply)UNCLAIMED_RECORDING_TTLis not set - no auto-deletion whatsoeverThe benefit of having 2-step auto-deletion process like this, especially for a main asciinema server instance - asciinema.org - is to give people time to reach out to the server admin until it's too late to recover the recording.
On asciinema.org we used
ASCIICAST_GC_DAYS=7and I plan to replace it with something likeUNCLAIMED_RECORDING_TTL=7,90.