Skip to main content

File deletion intermittently returns 500 before eventually succeeding

Bugs

Deleting a file from a project intermittently fails with a 500 before a later retry succeeds. Observed repeatedly on 15-16 July in production.

Evidence

  • One file returned 500 on four consecutive delete attempts, then succeeded.
  • A second file returned 500 twice before succeeding.
  • A third returned 500 twice the previous day.
  • One delete returned 200, and an immediate repeat of the same request returned 404 — so the client cannot tell a real failure from an already-completed delete.

Why it matters

Deletion is a data-protection operation. A customer clearing their own content sees an error and cannot tell whether the data was removed. Repeated retries also mean the cleanup path runs more than once for the same file.

Suggested next step

Capture the underlying error behind the 500 (the response body is generic), make the delete idempotent so a repeat returns success rather than 404, and surface a clear outcome to the user.

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.