SDK 0.4.34: responsive async image builds

Async image builds now prepare contexts in a bounded background pool, keeping sandbox and relay requests responsive. Submission deadlines include time waiting for preparation; canceled work cleans up its archive, retries reuse one snapshot, and workers reset safely after a POSIX fork. Sync archive bytes and the HTTP protocol are unchanged.

Validation: 187 tests passed locally in both the standard and Inspect-enabled suites; Python 3.10/3.13 CI checks minimal installation, lint, all extras, packaging and the installed wheel. A local four-context packaging comparison reduced wall time from about 1.31 s to 0.68 s and maximum event-loop heartbeat gap from about 1.30 s to under 9 ms; this is not an end-to-end image-build benchmark.

SDK 0.4.33: compact sandbox status inventory

Status-only polling can now request compact sandbox records instead of reading and transferring full specifications and snapshot descriptors. SDK 0.4.33 adds list_sandbox_statuses(sandbox_ids=...) and get_sandbox_status(sandbox_id) to both synchronous and asynchronous clients.

from ucloud_sandboxes_sdk import AsyncSandboxClient

async with AsyncSandboxClient.from_env() as client:
    statuses = await client.list_sandbox_statuses(sandbox_ids=["agent-1", "agent-2"])
    status = await client.get_sandbox_status("agent-1")

Omit sandbox_ids for all statuses. Exact-ID filters accept at most 256 IDs; an explicit empty list returns [] without making a request. Status records preserve state, cached state, worker placement, generation, and timestamps. The gateway must support view=status; unsupported or malformed responses raise SandboxApiError instead of silently returning an unfiltered full inventory.

Existing list_sandboxes() and get_sandbox() calls retain full-record behavior. Use the new methods explicitly where only status is needed. No dependency changes.

Install the versioned release wheel (the SDK is distributed through GitHub releases):

uv add "ucloud-sandboxes-sdk[async] @ https://github.com/rlrs/ucloud-sandboxes-sdk/releases/download/v0.4.33/ucloud_sandboxes_sdk-0.4.33-py3-none-any.whl"

Validation: all 176 tests passed on Python 3.10 and 3.13 with all optional integrations installed; Ruff and the minimal installed-wheel smoke test passed. Both clients passed a read-only production smoke test over verified HTTPS, including compact/full inventory and absent-ID filtering. Production inventory was empty during that smoke test; populated responses and malformed/legacy gateway responses are covered by protocol tests.

Commit: fecf8930e35ac3f5a5832eddde34a975bd2d6431.

SHA-256:

d15b65fbb5e1570fde69cb9d571789a9b61d4418682efc17732bdc9c2ca8414c  ucloud_sandboxes_sdk-0.4.33-py3-none-any.whl
f7128a710f5f8307baea3f7a45cf4aaaa8e2fe8de26cb8e0fc9d6592e786a43d  ucloud_sandboxes_sdk-0.4.33.tar.gz

SDK 0.4.32: retry pre-dispatch capacity waits and draining deletes

Retry capacity waits the gateway reports before dispatching anything, until the operation deadline: wake_destination_unavailable (a parked sandbox found no wake capacity, e.g. on a CPU-saturated node) and migration_destination_unavailable. Previously an exec that woke a parked sandbox gave up after 6 attempts; in a 500-sandbox load test 12 sandboxes failed a turn this way.

Retry DELETE /v1/sandboxes/ while the node reports memory_publication_draining (a just-parked sandbox is still uploading its memory); deletes are idempotent.

The new server-side codes ship in ucloud-sandboxes 0.5.114rc58.

SDK 0.4.31: connection reuse in the synchronous client

The synchronous client keeps HTTP/1.1 connections for reuse instead of opening a new TCP and TLS connection for every request, and builds its TLS context once. A connection returns to the pool only after its response body is fully read. Idle connections retire after 5 seconds, as in the async client, and a connection the peer has closed is discarded before reuse. Only GET and HEAD are resent after a reused connection fails. Proxied requests still use urllib.

On Hetzner, a sequential exec from a laptop took 81 ms instead of 196 ms, and client CPU for 50 concurrent execs fell from 17 s to 0.6 s. No backend version change is required.

SDK 0.4.30

Retry transient connection-establishment failures in sandbox requests within the original deadline, with at most five attempts and bounded backoff. Streaming bodies rewind before retry. Certificate failures, cancellation and ambiguous post-dispatch failures are not replayed. Final errors include the attempt count and underlying exception type.

Sync clients retry identified DNS, refused-connection and unreachable-host errors; async clients retry connector-establishment failures. No backend version change is required for this client behavior.

SDK 0.4.29

Report retry-budget exhaustion with HTTP attempt counts while preserving server status, body and headers. Qualify the exact gateway placement-busy response through real sync and async HTTP transports. Retry policy is unchanged.

Validation: 14 placement/image-poll tests and 28 existing retry/timeout tests passed locally.

SDK 0.4.28: resilient image build polling

Build-status polling now retries transient read timeouts, disconnects, and HTTP errors in sync and async clients. Retries use jittered backoff within the original build deadline and never resubmit the build. This prevents one transient shared poll failure from immediately failing all waiting rollouts.

Upgrade the SDK in the workload runner to receive this fix. No Verifiers API changes are required.

Validation: 76 focused client, Inspect, and polling tests pass, including eight waiters sharing a build through transient failures. Wheel and source distribution build successfully. The full 144-test suite has one local 512-upstream keepalive readiness failure, also reproduced against the unmodified client.

SDK 0.4.27: full duplex exec I/O

Exec now sends stdin and drains stdout/stderr concurrently in both sync and async clients. This avoids deadlocks with bounded server output backpressure. Failure and cancellation clean up peer I/O and stop the exec while preserving the original error.

Upgrade clients using large stdin before deploying server 0.5.114rc24. Streaming handle users must also drain events while writing input.

Validation: focused SDK client/duplex tests and real Linux HTTP/process tests; wheel and source distribution built from dc62af7.

SDK 0.4.26: shared relay admission and fenced resource hints

Relay workers now share an explicit in-flight request budget across rollout sessions. Polling reserves capacity before leasing work, while response submission and lease renewal retain independent connection capacity. Optional resource-phase hints are fenced to the active registration and remain advisory; they do not grant sandbox lifecycle authority.

Includes execution and receipt handling improvements since 0.4.23. Sync and async clients retain separate polling, forwarding, and control connection pools.

Built on Linux from commit e728daf. Validation: 133 Inspect-enabled SDK tests passed and the minimal wheel installed and passed its smoke test in a fresh environment. The source archive and wheel contain the release README from that exact commit.

SHA-256:

• ucloud_sandboxes_sdk-0.4.26-py3-none-any.whl: b39c74752c1286338bfc8904386004a7e73828219d1d3c86a631d7ba0b270724
• ucloud_sandboxes_sdk-0.4.26.tar.gz: 57a161def0ca5697b8b1cbe287b15455423830dc96c904704d9dbdab9d12abbc

SDK 0.4.25: reduce exec polling round trips

Exec waits now finish at the server-proven final output sequence, avoiding a redundant confirmation poll while preserving complete stdout/stderr. Short noninteractive execs can consume initial output in the start response; partial output continues through the existing event endpoint. Sync and async clients behave alike.

The initial-output optimization requires server 0.5.111 or newer. Older servers retain the existing polling behavior. This release includes the unpublished 0.4.24 final-sequence improvement.

Validation: Linux CI passed on Python 3.10 and 3.13 for the runtime code. The published wheel has byte-identical runtime files to the SDK used in production qualification: 2,048 successful cycles at 256 agents, plus 256 forced park/restore cycles. These are correctness results, not a guarantee of subsecond latency at every load.

Install the async client:

uv add "ucloud-sandboxes-sdk[async] @ https://github.com/rlrs/ucloud-sandboxes-sdk/releases/download/v0.4.25/ucloud_sandboxes_sdk-0.4.25-py3-none-any.whl"

The wheel, source distribution, and SHA256SUMS are attached. The SDK is distributed through GitHub releases, not PyPI.