Give sandbox task creation a realistic timeout and diagnosable failures

[Osvaldo Ortega (osortega)]

Creating a cloud sandbox task ran on the generic 10s request budget, but the call waits on a sandbox environment being provisioned rather than on a record being written. Successful creates routinely take considerably longer than that, so every create was aborted client-side before any response arrived. It surfaced as a network failure, when really we were hanging up while the request was still in flight.

What this does

Task creation gets its own 60s budget. Other calls keep the 10s one.

Failures are now diagnosable. A failed create can come back with a generic message that does not identify the underlying cause, so nothing client-side can explain it on its own. Failed creates now log the response verbatim — status, body, and x-github-request-id, which is what a support escalation is keyed on. A small set of retry-related response headers is captured for the same reason.

Orphaned tasks are cleaned up. A task record can already exist by the time a create fails, so a failure can leave one behind — not just the authorization rejection that was previously handled. When the response names the task, it is deleted; when it does not, the log says so explicitly rather than staying silent about something that can then only be removed server-side.

A rejected cleanup is no longer reported as a successful one. _request resolves non-2xx responses rather than throwing, so a failed DELETE was logged as "Cleaned up" while the orphan was still there. The status now decides, and a rejected delete takes the same warning path as a thrown one.

Two subtleties worth a reviewer's eye

• asText(context) consumes the stream. Reading it twice silently yields an empty string, which was dropping the message explaining the failure — so the body is read once and threaded through to _throwForStatus.
• No blind retry on 5xx. It is tempting, but a generic 500 here does not by itself indicate a retryable condition, and the backend signals genuinely retryable failures explicitly — ours carried no such signal. Retrying blind would also multiply the orphaned tasks.

Also fixes a hardcoded GET in the request failure log, and sends Content-Type: application/json for bodied requests, which fetch would otherwise label text/plain.

Validation

• npm run typecheck-client, eslint on both changed files
• ./scripts/test.sh --glob "**/cloudSandboxApiService.test.js" — 17 passing

Each new assertion was checked against the bug it is meant to catch, by reverting the production change and confirming the test fails:

Reverted	Test that fails
60s create budget	posts the on-demand sentinel and returns the bound environment
Content-Type: application/json	same
isSuccess check on cleanup	reports a rejected cleanup rather than claiming the orphan was removed

The request stub previously discarded timeout and headers, so an earlier revision of this PR would have stayed green with the budget and content type reverted. It no longer does.

[Copilot]

Pull request overview

Adds reliable cloud sandbox task creation and failure diagnostics.

Changes:

• Extends creation timeout to 60 seconds and sends JSON content type.
• Logs failure details and attempts orphan cleanup.
• Adds failure and cleanup tests.

Show a summary per file

File	Description
cloudSandboxApiService.ts	Updates request handling, diagnostics, and cleanup.
cloudSandboxApiService.test.ts	Adds failed-create tests and log assertions.

Review details

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Balanced