Sandboxes: exec on a newly created sandbox returns as soon as the command exits
In some regions, POST /v1/sandboxes/{id}/exec on a sandbox created at the default size could hang until the client's timeout. The first exec after a create now returns in about 35 ms, and later ones in about 6 ms.
API keys limited to a compartment reach only that compartment's sandboxes
On Runtime 2.0, a key limited to one compartment (project) now lists only that compartment's sandboxes, and GET, DELETE, :exec, files, processes and every other sandbox route return 404 for a sandbox in another compartment, the same response as for a sandbox that does not exist. A sandbox created on Runtime 2.0 before this change has no recorded compartment: a compartment's key reaches it only if that key created it. Account-wide keys still reach every sandbox in the account. A create with a name that a sandbox the key cannot reach holds returns 409 name_taken without naming that sandbox, and getOrCreate never returns it.
CI/CD: a failed job's reason names its first error
The reason shown for a failed job, in the console and on its GitHub check run, was the last line of its log, which for a build is often a line such as error: build failed, waiting for other jobs to finish.... It is now the first error line that names a cause (for example error[E0308]: mismatched types), or a No space left on device line when the machine ran out of disk. When a long log is shortened, every error line is kept, including error: lines without a code, and a compiler's quoted source lines are no longer taken for an error.
API v2: filter sandboxes and other machines by phase
The lists of sandboxes, browsers, desktops, dev environments, databases, Kubernetes clusters and notebooks (GET /v2/{resources}) accept phase (pending, running, paused, stopped or failed) and return only the resources in that phase. For example, GET /v2/sandboxes?phase=running returns the running sandboxes. The filter reads an index that is updated in the same write as the status, so a resource appears under its new phase as soon as its status shows it. The TypeScript, Python, Go, Ruby and Java SDKs take phase in each of these lists' filtered queries.
API v2: lists return the API v1 ID of each moved resource with include=movedFrom
Every v2 list (GET /v2/{resources}) accepts include=movedFrom, which adds movedFrom to the page: the ID of each item that moved in from API v1 mapped to the ID it had there. Items created in v2 are not in it. On a metered resource, include=usage,movedFrom returns both. Any other include value returns 400. The TypeScript, Python, Go, Ruby and Java SDKs return the page's movedFrom, and the CLI takes --include movedFrom.
API v2: lists return each resource's usage to date with include=usage
A list of a metered resource (GET /v2/{resources}, for every resource that has :usage) accepts include=usage, which adds usage to the page: each item's ID mapped to what it has used from the month it was created (since) to now, with the same figures as :usage (windows, heldMs, cpuBilledUsec, memoryMibMs and chargedMicros), summed over those months. The page is still one request, so a list that shows each resource's cost no longer needs one :usage call per item. Any other include value returns 400, as does include on a resource that is not metered. The TypeScript, Python, Go, Ruby and Java SDKs take include on list and return the page's usage, and the CLI takes --include usage.
API v2: lists return resources newest first with order=newest
Every v2 list (GET /v2/{resources}) accepts order=newest, which returns resources by createdAt, newest first, and pages with cursor as before. order=oldest, the default, keeps today's ID order. Labels and filters apply on top of either order. A key limited to the resources it created returns 400 for order=newest. The TypeScript, Python, Go, Ruby and Java SDKs take order on every list, and the CLI takes --order oldest|newest.
Sandboxes: commands run as the sandbox user, and the HTTP proxy works at every size
On some sandboxes, commands, processes, terminals and file writes ran as root even though the sandbox reported user: "sandbox". They now run as the sandbox user (uid 1000) with its HOME, and files written through the files API are owned by that user, as on every other sandbox; user: "root" still runs a command through sudo. On those sandboxes, every request sent through the built-in proxy (HTTPS_PROXY, http://127.0.0.1:10800) at a size other than the default returned 502 with Connection reset by peer; the proxy now carries them. /workspace is owned by the sandbox user, the host name runtime-guest resolves (so sudo no longer prints unable to resolve host), and PATH, NO_PROXY and NODE_USE_ENV_PROXY are set as on every other sandbox.
Sandboxes: bucket mounts succeed and stay mounted
POST /v1/sandboxes/{id}/mounts checked whether the mount's client was still running by the size of its cgroup's process list, which the kernel always reports as 0. Every mount was therefore taken for a client that had exited: the request returned 422 mount_failed with "the bucket did not mount", and the client was stopped even when the bucket had mounted. The check now reads the process list itself. A mount returns 200 once the bucket is mounted, GET /v1/sandboxes/{id}/mounts reports mounted: true for it, and POST /v1/sandboxes/{id}/mounts:unmount waits for the client to exit before it returns.
Sandboxes: sessions work for every sandbox
POST /v1/sandboxes/{id}/sessions, GET /v1/sandboxes/{id}/sessions and POST /v1/sandboxes/{id}/sessions/{sessionId}:revoke now work for every sandbox, and the rtsess_ token a session returns can be used with every sandbox. Previously, these requests returned 409 served_elsewhere for some newly created sandboxes. Sessions behave as before: a token reaches only its own sandbox's commands, files and previews, from the origins it lists, and is rejected with 401 on its next request once it is revoked or expires, or once the API key that created it is revoked.