<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=467674) </details> <!--IssueSummary end--> This is a follow-up issue from https://gitlab.com/gitlab-org/gitlab/-/issues/408469#note_1930624460 > It just means we start to export more things on disk, so we probably need a cron job for direct transfer exports to clean up old exports. **We do the cleanup for file-based, but I don't think we do for DT.** (emphasis mine) The exports associated with file-based exports are pruned in `Gitlab::Export::PruneProjectExportJobsWorker` & `Projects::ImportExport::PruneExpiredExportJobsService`. We need to either update these create equivalent workers & cron schedule to handle exports generated by Direct Transfer. I think the key logic is: ```ruby BulkImports::Export.where(created_at: ..1.week.ago).each(&:remove_existing_upload!) ``` * The existing logic for starting a new export removes the attached file, but keeps the `BulkImports::Export` record itself. * 7 days matches the expiry defined in `ProjectExportJob`