test(isolate): AWS integration-harness coverage + create-latency benchmark

[sumansaurabh]

Summary

• Adds the first AWS integration-harness coverage for the V8-isolate (workerd) runtime: a single-node-isolate scenario, CapIsolate + UC-103/104/105, make integration-single-isolate, and a UC-94 isolate create-latency benchmark (make integration-benchmark-isolate). Before this, isolate — and the per-sandbox egress attribution shipped in v0.7.16 / feat(isolate): per-sandbox egress attribution via per-slot service pool #340 — was only ever validated by an ad-hoc manual recipe, so it left no reports/*.md and had no make target.
• Test-harness only — no runtime, server, pkg/, or SDK code changes. The isolate provisioning layer already existed (install.sh --with-isolate downloads a SHA-pinned workerd + writes SB_ENABLE_ISOLATE=true; Terraform default_with_isolate; bootstrap.sh.tftpl emits the flag), so this is purely the harness layer, mirroring how gvisor is wired (advertisement-only capability, provisioning-driven, no config-overlay flip and no node-side staging — the UCs upload JS bundles over POST /v1/js-bundles at runtime).
• Live-validated end to end on real AWS with the released v0.7.16 binary + workerd (no scp/cross-compile — a vanilla provision is production-faithful).

Code-path diagram

flowchart TB
  subgraph provision["make integration-single-isolate → run.sh single-node-isolate"]
    TF["Terraform apply<br/>default_with_isolate = true"] --> INS["install.sh --with-isolate<br/>SHA-pinned workerd → /usr/local/bin/workerd<br/>+ SB_ENABLE_ISOLATE=true"]
    INS --> EUD["extra_user_data (NEW)<br/>SB_ISOLATE_USE_JAIL=false + restart sandboxd"]
    EUD --> HEALTH["wait DNS/TLS/health → isolate:ok<br/>supported_runtimes=[docker,isolate]"]
  end
  subgraph suite["integration suite — CapIsolate gates (NEW)"]
    HEALTH --> U103["UC-103 upload bundle → create isolate → exec-fetch"]
    HEALTH --> U105["UC-105 js-bundle catalogue CRUD"]
    HEALTH --> U104["UC-104 two sandboxes / one tenant:<br/>allow-list vs block-all egress differ"]
    HEALTH --> U94["UC-94 (bench, AEROL_BENCH=1 only)<br/>warm create latency, 10 samples"]
  end
  U103 --> RPT["report matrix + auto-teardown"]
  U104 --> RPT
  U105 --> RPT
  U94 --> RPT

Loading

Before → after: before this PR there was no isolate scenario/UC/target and no isolate row in any report; after, single-node-isolate provisions the runtime through the existing --with-isolate path and the suite exercises create/exec, per-sandbox egress, the bundle catalogue, and create latency.

Sandbox boot impact

N/A — test harness only; no work added to CreateSandbox or any callee. The one node-side change the scenario makes is appending SB_ISOLATE_USE_JAIL=false to sandboxd.env via extra_user_data (a provisioning-time env write + restart, the same hook the wasm/gvisor scenarios use), not a code path in the boot sequence.

Idempotency

N/A — no API surface changed. The UCs are clients of existing endpoints: js-bundle upload is content-addressed and idempotent (re-upload of the same name+source resolves to the same digest), and sandbox create/destroy are unchanged. The bench reuses one uploaded bundle + one shared tenant across all samples precisely because upload is idempotent.

Failure-path consistency

N/A — no multi-step caddy+store write path changed. Isolate is HTTP-only / host-mediated and the change is test-only. The harness's own hygiene is unchanged: every created sandbox registers a t.Cleanup destroy, and run.sh (no --keep) tears the deployment down on EXIT/INT/TERM and collects reports/<scenario>-failure-logs.txt before teardown on any failure.

L4 / host-port-pool changes

N/A — neither touched. Isolate never calls TryReserveHostPort / allocateHostPort / EnsureLayer4 / the l4Ready latch; the harness adds no L4 code.

Test plan

• Offline: go vet -tags=integration ./integration-tests/suite/... (exit 0); go test ./integration-tests/suite/harness/... (green — includes the known-capability check extended with CapIsolate); go test ./integration-tests/report/... (green — registry-driven, classifies the new UCs); make fmt clean.
• Live functional (make integration-single-isolate, fresh t3.medium, released v0.7.16 + workerd): pass 57 · fail 0 · skip 51 · inconclusive 0. UC-103/104/105 all green. UC-104 proved per-sandbox egress attribution on real infra — an allow-listed sandbox reached example.com (200) but 403'd a non-allowed host, while a block-all sandbox in the same tenant group 403'd everything. Torn down clean (34 resources destroyed, no leak).
• Live benchmark (make integration-benchmark-isolate, 10 samples): warm isolate create server p50 = 4 ms / p90 = 6 ms / p99 = 19 ms, 0 failures (stages: create 6 ms mean, cluster_promote 4 ms, create_with_id 1 ms, cluster_seal 0 ms). The ~262 ms api↔server gap is laptop→us-east-1 WAN, not create cost. Torn down clean (34 resources destroyed, no leak).

Deliberate scope note

The scenario runs the isolate jail off (SB_ISOLATE_USE_JAIL=false). The jail defaults on, but its chroot is not yet populated with the workerd binary (chroot-populate is the tracked "full jail realization" follow-up in plans/isolate-runtime.md); with the jail on, workerd is exec'd inside an empty chroot and every create fails no such file or directory even though the binary is installed and health reports isolate:ok. Jail-off is how the runtime is currently deployable end to end, and is orthogonal to the egress attribution UC-104 proves. Follow-ups: a jail-ON isolate scenario once chroot-populate lands.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	microvm	c0aafa2	Commit Preview URL Branch Preview URL	Jul 18 2026, 08:55 AM