[pmakanju-e2b]

Why

The templates (#539) and builds (#541) reads moved to api, so the dashboard no longer calls any dashboard-api route. What was left was a client, URL settings, a health probe and generated types. Removing them lets dashboard-api be retired without breaking the dashboard.

Changes

• Client: src/core/shared/clients/api.ts exports only the infra client. The dashboard-api api client is gone.
• Health: GET /api/health probes api's GET /health (unauthenticated, 204) instead of dashboard-api's. The response key changes from checks.dashboardApi to checks.infraApi, and the log key from health_check:dashboard_api_error to health_check:infra_api_error.
• Settings: E2B_DASHBOARD_API_URL, NEXT_PUBLIC_DASHBOARD_API_URL and resolveDashboardApiUrl are removed. Leftover values are ignored rather than rejected, so existing deployments keep starting after the upgrade (on main, a leftover NEXT_PUBLIC_DASHBOARD_API_URL fails validation). A unit test covers unknown variables being ignored.
• Sandbox details: removed the database-record source that wrapped dashboard-api's SandboxRecord. It was never produced (the repository always returned 404), and its mapper mapApiSandboxRecordToModel and the router branch are gone too. The 'infra' source and the rest of the sandbox details flow are unchanged.
• Contracts and tooling: deleted spec/openapi.dashboard-api.yaml, dashboard-api.types.ts, the generate:dashboard-api script, the tsconfig path and .gitattributes (it held only those two entries). The spec sync workflow now syncs only the infra spec.
• Docs: README, .env.example, scripts/container-smoke.sh and a cookie comment no longer mention dashboard-api.

Verification

All through bun 1.4.4:

• bun run check: clean (same 130 warnings as main).
• bun run knip: no new findings.
• tsc --noEmit (after next typegen): 0 errors.
• bun run test:unit: 31 files, 315 tests pass.
• vitest run tests/integration/ with PUBLIC_E2B_DOMAIN=example.dev: 5 files, 19 tests pass.
• bun run build with PUBLIC_E2B_DOMAIN=example.dev: succeeds.
• Ran the real env validator with both removed variables set: it passes on this branch and fails on main.
• scripts/container-smoke.sh was not run (needs Docker).

Rollout

• Monitoring that reads checks.dashboardApi from /api/health needs to read checks.infraApi instead.
• /api/health now answers 503 when api is unreachable, rather than when dashboard-api is.
• Deployments can drop the dashboard-api URL settings at any time; they are ignored.

[linear-code]

BKND-133

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟣 src/app/api/health/route.ts — Operators can see /api/health answer 200 ok while infra-api is failing, whenever infra-api or its proxy sends a non-2xx with an empty body. The probe treats !error as healthy (src/app/api/health/route.ts:10). openapi-fetch sets error to undefined for a non-ok Content-Length: 0 reply, and to "" for other empty error bodies. Fix: decide health from the HTTP status, e.g. const { response } = await infra.GET('/health', {}); if (response.ok) return true, and log response.status on failure. Pre-existing: the base probe had the same check, and this change carries it over to infra-api.

  Why this was flagged

  Trigger: infra-api, or a load balancer or ingress in front of it, answers GET /health with a 5xx/4xx and an empty body, for example a proxy 502/503 with Content-Length: 0. The spec declares /health bodiless (204, content?: never in infra-api.types.ts:28-32), so empty bodies are the native shape for this endpoint. openapi-fetch ^0.14 (package.json:93) returns { error: undefined, response } for a non-ok Content-Length: 0 response. For other non-ok replies it sets error to await response.text(), which is "" for an empty body. checkInfraApi in route.ts:247-250 then sees !error as true and returns true. GET then sends 200 { status: 'ok', checks: { infraApi: true } } and logs no health_check:infra_api_error. Monitoring that switches to checks.infraApi, as the rollout notes ask, therefore misses this outage. Pre-existing: the base api.GET('/health') probe made the same !error check.

  Verification: Pre-existing. The check in src/app/api/health/route.ts (around lines 8-11, not line 250) is const { error } = await infra.GET('/health', {}); if (!error) { return true }, so health is decided only by whether error is truthy. Network errors throw, get caught and return false, so only empty-body non-2xx replies slip through.