fix(api): DELETE /sandboxes/{id} returns 500/404 with no structured log — root cause invisible
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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