feat: add HTTP/2 load testing infrastructure

[jrvb-rl]

User description

Summary

A loadtest/ toolkit for benchmarking the SDK's request handling, plus raw-transport baselines. The SDK harness (loadtest.ts) fires a burst of devboxes.create calls at a deliberately nonexistent blueprint (bp_nonexistent_loadtest_00000): every request fails fast server-side (HTTP 400, no devboxes created), isolating client + server request handling from provisioning — i.e. "can the stack absorb many requests at once."

What changed in this update

• Runs against the in-repo SDK. loadtest.ts now imports ../src/sdk.ts (like the sibling loadtest scripts) instead of the published @runloop/api-client, so it always exercises the SDK code in the current checkout — not a stale build.
• Matches HTTP/2-as-default. Transport is set explicitly: since HTTP/2 is now the default, HTTP/1.1 must be opted into with http2: false. USE_HTTP2 defaults to on; USE_HTTP2=0 benchmarks HTTP/1.1. HTTP/2 mode relabeled as native node:http2.
• Kept the undici comparison. The raw undici / node:http2 / node:https probes are retained — comparing undici's HTTP/2 multiplexing against node:http2 is the comparison that motivated building the SDK's own node:http2 transport. undici now lives in loadtest/package.json, so these stay runnable even after the SDK drops its undici dependency (chore(deps): remove dead undici HTTP/2 adapter and dependency #817).
• package.json: dropped type: module (it would force the shared loadtest/ dir to ESM and break push-to-loki.ts) and the @runloop/api-client file dependency.
• README: documents the real-API comparison scripts and how to run them.

Scripts (real-API)

Script	Transport under test
loadtest.ts	The SDK (HTTP/1.1 vs native HTTP/2), via a bogus-blueprint create burst
undici-test.ts, undici-single-conn.ts, undici-debug.ts	Raw undici HTTP/2 pool
h2-test.ts, h2-single-conn.ts	Raw node:http2
raw-fetch-test.ts	Raw node:https (HTTP/1.1 keep-alive)
alpn-check.ts	TLS ALPN h2 negotiation check

Usage

# SDK: HTTP/2 (default) vs HTTP/1.1
source ~/env && REQUEST_COUNT=2000 npx tsx loadtest/loadtest.ts               # HTTP/2
source ~/env && REQUEST_COUNT=2000 USE_HTTP2=0 npx tsx loadtest/loadtest.ts   # HTTP/1.1

# Raw undici vs node:http2 (undici from loadtest/package.json)
cd loadtest && npm install && source ~/env && npx tsx undici-test.ts

Relationship to #815

The HTTP/2-as-default behavior (and the single shared H2 pool + idle-session unref) lands in #815. Run this harness against a checkout containing #815 to exercise the proposed transport; the comparison numbers in #815's description were gathered with this harness against that branch. On plain main (pre-#815), loadtest.ts in HTTP/2 mode will not exit on its own because idle H2 sessions aren't unref'd until #815.

Test plan

• loadtest.ts runs against the in-repo SDK for both transports; HTTP/1.1 and (against feat: default to HTTP/2 transport on Node #815) HTTP/2 complete and exit cleanly, all requests 400 (no devboxes created).
• eslint clean on loadtest.ts.

🤖 Generated with Claude Code

---

CodeAnt-AI Description

Add real API load tests for HTTP/2, HTTP/1.1, and raw client comparisons

What Changed

• Added load test scripts that run against the real Runloop API and compare the SDK, raw HTTP/2, raw HTTP/1.1, and undici behavior
• The SDK load test now always uses the local checkout and can switch between HTTP/2 and HTTP/1.1, with request counts, progress updates, throughput, latency percentiles, and status counts in the output
• Added single-connection, multi-connection, and protocol-check scripts to make transport comparison and HTTP/2 negotiation checks easier
• Load tests now fail instead of hanging when the server aborts a response, and the README explains which scripts use real API traffic and how to run them

Impact

✅ Clearer HTTP/2 vs HTTP/1.1 benchmark results
✅ Fewer stuck load tests when responses fail mid-stream
✅ Easier comparison of SDK and raw client request handling

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[codeant-ai]

CodeAnt AI is reviewing your PR.

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[codeant-ai]

CodeAnt AI finished reviewing your PR.

[codeant-ai]

CodeAnt AI is running Incremental review

[codeant-ai]

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[codeant-ai]

CodeAnt AI Incremental review completed.