e2b-dev / e2b-dev/runtime

Template deletion does not remove build artifacts from storage (GCS/S3)

Open
#3,239 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
1.6k
Forks
438
PR merge metrics
No merged PRs in 30d

Description

Summary

When a user deletes a template via DELETE /templates/:templateId, the API only soft-deletes the database record. The associated build artifacts in GCS/S3 are never removed.

Steps to Reproduce

  1. Build a template and verify its build artifacts exist in storage.
  2. Delete the template via DELETE /templates/:templateId.
  3. Observe that the build objects remain in GCS/S3 indefinitely.

Expected Behavior

Template deletion should clean up build artifacts that are no longer referenced by any other template.

Actual Behavior

softDeleteTemplate() in api/internal/handlers/template_delete.go only performs DB operations:

  • SoftDeleteTemplate
  • ReleaseTemplateAliases
  • DeleteActiveTemplateBuilds

No storage cleanup (DeleteObjectsWithPrefix / DeleteObjects) is triggered at any point in the user-facing delete flow.

Evidence of Planned but Incomplete Implementation

The query db/queries/builds/get_exclusive_builds_for_template_deletion.sql already exists with the comment:

"Returns builds that are ONLY assigned to this template (safe to delete)"

However, this query has no Go callers — the storage cleanup logic that was meant to consume it was never implemented.

The only code path that calls DeleteObjectsWithPrefix on template builds is the internal TemplateBuildDelete gRPC handler, which is invoked only by admin build-cancel and a deprecated build-start flow — not by user template deletion.

Impact

  1. Storage leak: Deleted template artifacts accumulate indefinitely in GCS/S3, incurring ongoing storage costs.
  2. Runtime I/O errors (potential): If an external GCS lifecycle policy or manual GC later removes these objects, any sandboxes still using that build will encounter object does not exist errors propagating as NBD read failures and Firecracker disk I/O errors (EIO), crashing the sandbox filesystem.

Suggested Fix

On DELETE /templates/:templateId, after marking the template as deleted:

  1. Call GetExclusiveBuildsForTemplateDeletion to find build IDs solely owned by this template.
  2. For each such build, invoke TemplateBuildDelete (or call DeleteObjectsWithPrefix directly) to remove the GCS/S3 artifacts.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in api/internal/handlers/template_delete.go and trace softDeleteTemplate() through the existing GetExclusiveBuildsForTemplateDeletion query in db/queries/builds/get_exclusive_builds_for_template_deletion.sql. Review the TemplateBuildDelete handler and its DeleteObjectsWithPrefix/DeleteObjects calls. Done means user-facing template deletion removes artifacts exclusive to that template while preserving shared builds.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, gcp, go
Domain
backend, cloud
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.