Skip to main content

Deleted files leave source uploads and attachment blobs in storage

Bugs

When a file is deleted, the database rows are removed and the logs report success, but the underlying objects stay in Cloud Storage indefinitely.

Evidence (production, 16 July deletion, still present 20 July)

  • Logs show the full happy path: Attachments cleaned up and unreferenced blobs queued for reap, Starting async PDF cleanup, File deleted successfully.
  • Despite this, thousands of attachment blobs remain under the project's attachments/ prefix in the uploads bucket.
  • The original uploaded source files also remain under the user's uploads/ prefix — they do not appear to be removed by the delete path at all.
  • Four days later none of these objects have been reaped.

Why it matters

This is a retention and data-protection gap, not just wasted storage. A customer who deletes their content — often the whole point of a redaction workflow — still has the original documents and attachments held on our infrastructure, including personal data belonging to third parties. Deletion must actually delete.

Suggested next step

Verify the reap queue is receiving rows and is actually being drained, confirm the delete path removes the source upload as well as attachments, and backfill a cleanup for objects already orphaned by past deletions.

Posted by Harry Elliott ·
Status: Completed2 comments

Log in to comment and vote

Comments2

  • Harry Elliott

    Team•

    Jul 21

    This is now live.

    Deleting a file now clears its attachments and the original uploaded file from storage properly. Previously the items disappeared from your project but the underlying files stayed behind — that's fixed, and we're clearing the historic backlog separately.

    The intermittent errors on delete are also gone. A large file that previously took over a minute and timed out now deletes in under a second.

  • Harry Elliott

    Team•

    Jul 21

    Both of these turned out to be the same area of code, and both are now fixed and awaiting deployment.

    Deleted files were leaving their attachments and original uploaded file behind in storage. The delete looked like it worked — the items disappeared from your project — but the underlying files weren't being cleared. That's fixed, and we're clearing the historic backlog too.

    The intermittent errors on delete were a database query getting slower the more items a file held, until it outran the request timeout. You'd see an error even though the delete had actually gone through. That query is now roughly 80x faster, so it completes well inside the limit.

    I'll update again once it's live.