e2b-dev / e2b-dev/runtime

fix(api): DELETE /sandboxes/{id} returns 500/404 with no structured log — root cause invisible

Open
#3,529 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

Problem

DeleteSandboxesSandboxID can return HTTP 500 or 404 with no structured log entry that explains why, making production incidents hard to diagnose.

500 — ErrSandboxOperationFailed path has no log at all
case errors.Is(err, orchestrator.ErrSandboxOperationFailed):
    a.sendAPIStoreError(c, http.StatusInternalServerError, ...)  // no log, no telemetry
    return

This is the most common 500 cause (node unreachable, gRPC error during kill), yet nothing is written to Loki and no span error is recorded. The only signal is the ALB upstream status code.

404 — logged at Debug level, missing teamID
logger.L().Debug(ctx, "Sandbox not found for deletion", logger.WithSandboxID(sandboxID))

Debug level is suppressed in production by default, so 404 responses leave no queryable trace. There is also no teamID field, preventing per-team filtering.

deleteSnapshot failure message is ambiguous

telemetry.ReportError(ctx, "error deleting sandbox", ...) does not distinguish between a kill failure and a snapshot DB failure.

Impact

  • On-call cannot distinguish node crash (500) from DB error (500) without reading gRPC traces
  • 404 frequency per team is invisible — no Loki query possible
  • Incident response requires guessing which layer failed

Reproduction

Any DELETE /sandboxes/{id} where:

  • The orchestrator node is unreachable → 500 with zero log
  • The sandbox never existed → 404 with zero visible log

Expected behaviour

Each terminal branch emits a structured log at the appropriate level (Error / Info) with sandbox_id, team_id, and the full error field so operators can query Loki directly.

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 at the DeleteSandboxesSandboxID handler and inspect each terminal error branch, including ErrSandboxOperationFailed, the not-found path, and deleteSnapshot failures. Reproduce the documented DELETE scenarios, then verify that each response produces a structured log with sandbox_id, team_id, and the full error at an appropriate level.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, backend, observability
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.