Module openai 

OpenAI-compatible inference gateway shim.

v0.3.5 landed the scaffold (request types, error envelope, two handlers returning 501 openai_not_yet_wired); T41 (v0.4) wires the handlers through to the internal invoke protocol. The handlers accept the standard OpenAI request bodies (so off-the-shelf SDKs send valid JSON) and now resolve the model field against an env-configured model → function_uuid map, dispatch the call via the shared tensor_wasm_exec::executor::TensorWasmExecutor, and wrap the guest output in the OpenAI response envelope (or stream it as OpenAI-shape data: SSE frames when stream: true).

Legacy 501 Not Implemented error envelope shape (still emitted by the deprecated OpenAiError::not_yet_wired helper for routes that deliberately remain stubs):

{ "error": {
    "message": "...",
    "type":    "not_implemented",
    "param":   null,
    "code":    "openai_not_yet_wired"
}}

The v0.4 follow-up wires the actual translation step (resolve the requested model to a deployed FunctionRecord, marshal the prompt / messages into the wasm guest’s _start argv, stream tokens out as OpenAI-shape data: SSE chunks). The scaffold exists so:

• the route shape (path, method, request body) is locked in early — clients can begin integrating against the gateway’s URL surface without depending on the translator’s readiness;
• the error envelope shape (the four-field OpenAI object, distinct from the gateway’s native { error: { kind, message } } shell) is committed to the public contract and exercised by integration tests;
• the OpenAPI spec at openapi/tensor-wasm-api.yaml documents the surface up front, so downstream API-doc tooling renders both surfaces from a single source.

Security: tenant resolution

OpenAI clients send Authorization: Bearer <api_key> but never an X-TensorWasm-Tenant header. The gateway’s native routes derive the tenant from that header (via the tenant_scope middleware); the OpenAI routes cannot, because the header is absent on the wire.

The v0.4 implementation will derive the tenant from the bearer token’s TokenScope: a scoped token (mykey:tenant=7) implies tenant 7; a wildcard token implies the default tenant (0) with a one-shot warning. Clients should provision one bearer token per tenant in $TENSOR_WASM_API_TOKENS. This is why the OpenAI routes are mounted outside the tenant_scope middleware in server.rs — the layer would reject every OpenAI request as missing_tenant 400 otherwise.

Bearer auth itself still runs on these routes (mounted inside the bearer_auth middleware): an unauthenticated OpenAI client must receive 401, not 501. The current scaffold leaves the auth / rate-limit / audit composition for the server module to wire; this file owns only the request type definitions, the error envelope, and the two handlers.

Structs

ChatCompletionsRequest

Body of POST /v1/chat/completions.

ChatMessage

One entry in the messages array of POST /v1/chat/completions.

CompletionsRequest

Body of POST /v1/completions.

OpenAiError

Top-level OpenAI error envelope: { "error": { ... } }.

OpenAiErrorBody

Inner OpenAI error body. The shape is:

Functions

chat_completions_handler

POST /v1/chat/completions — OpenAI chat-completions shim, wired through to the internal invoke protocol (T41, v0.4).

completions_handler

POST /v1/completions — OpenAI completions shim, wired through to the internal invoke protocol (T41, v0.4).