Files
zeekay 8e00304bca e2e: run the clients against a real cloud
Every gate in this repo compares a client to the document, and every build
proves the client is well-formed. Neither answers the question a user actually
has: does it work against a server. Seven languages now answer it -- go, python,
typescript, dart, php, ruby, rust -- against the local cloud by default and
against anything HANZO_BASE_URL names.

Each probe asserts a 200 whose body decodes AND a 403 that arrives as an error,
because a client that swallows a refusal and returns a zero value looks exactly
like one that works.

It earned its place on the first run: GET /v1/models is AiAPI.GetModels in Go
and ai_api::get_models in Rust but ModelsApi.getModels in TypeScript. One
document, three groupings, and nothing but a call finds it.
2026-08-28 12:14:01 -07:00

1.5 KiB

e2e — the clients against a real cloud

generate.py --check proves a client is the projection of the document. A compile proves it is well-formed Go, Dart, PHP. Neither proves it can reach a server, decode a body, or turn a refusal into an error.

That last one is the trap. An SDK that swallows a 403 and hands back a zero value is indistinguishable from one that works, right up until production. So every probe asserts the same two things, in each language:

  1. GET /v1/models answers 200 and the body decodes to a non-empty list.
  2. GET /v1/engine/status — which needs a caller who is signed in — comes back as an ERROR carrying 403, not as an empty success.
./run.sh                                   # against the local cloud
HANZO_BASE_URL=https://api.hanzo.ai ./run.sh

Both are read-only GETs. The probe never writes.

What it found the first time it ran

The same operation does not live in the same place in every client. GET /v1/models is AiAPI.GetModels in Go and ai_api::get_models in Rust, but ModelsApi.getModels in TypeScript — one document, three groupings. Nothing catches that except calling it.

Not covered

java and kotlin need a jar on the classpath, swift needs macOS, cpp needs a build. They are exercised by hand today; adding them here needs a toolchain step, not another probe.

The probes are unauthenticated, so they cover transport, routing, decoding and the refusal path — not an authorised round trip. Anything past a 403 needs a credential this harness deliberately does not hold.