feat: return raw bytes from call_runner for non-JSON responses

[rickstaa]

Closes the last gap after #25: the buffered call_runner path required every response to be a JSON object, so binary-returning apps (an image, say — the hf-inference text-to-image API returns raw image/jpeg bytes) forced a base64-in-JSON shim into every runner and client. Streaming already handled bytes (stream=True → aiter_bytes()); this brings the buffered path to parity.

What

• http.request_data() — same request semantics and error mapping as request_json, but returns (body_bytes, content_type) without assuming JSON. request_json is now a thin wrapper over it (fetch + parse), behavior unchanged.
• call_runner (non-stream): single-document JSON — application/json or an RFC 6839 +json suffix — parses into result.data exactly as before (including the strict object check and session_id pickup). Any other content type returns result.content (bytes) + result.content_type instead of raising "expected JSON object".
• LiveRunnerCallResult: new optional content and content_type fields; content_type is also set on JSON results. content is None for JSON — b"" is a valid empty binary body, so None is the unambiguous "this was JSON" sentinel.
• Payment path untouched: the 402 challenge raises on status before any body handling, so paid calls work identically for JSON and binary responses.

Compatibility

Strictly additive: every response that succeeded before behaves identically. The only changed cases previously raised — a non-JSON content type now succeeds with bytes.

Content-type matching is by media subtype rather than a substring test, so vendor types (application/problem+json, application/vnd.acme.v1+json) parse without being listed, while multi-document formats that json.loads cannot parse (application/jsonl — this repo's own trickle-channel default — plus application/x-ndjson, application/json-seq) return bytes instead of raising. All four flipped classifications were previously errors.

One edge note: a server returning JSON under a non-JSON content type (e.g. bare text/plain) lands in content instead of being parsed; aiohttp's json_response (what the examples use) always sets application/json.

The field is named content, not raw, because raw already means "the original JSON dict" on LiveRunnerSessionEvent, LiveRunnerInstance, and LiveVideoToVideo — result.content would otherwise sit one dot from result.runner.raw with the opposite meaning. It also matches the requests/httpx convention for a body as bytes.

Why

With this, a runner that fronts a bytes-returning API needs no transform at all — the example-apps api-proxy can drop its base64 envelope, and a runner can literally be a stock nginx proxy_pass (see livepeer/runner-app-examples#45).

Tested

tests/test_call_runner_raw.py (7 cases against a live aiohttp server): JSON unchanged incl. session_id, +json vendor type parsed, binary → content + content_type, ndjson → content, invalid JSON with a JSON content type still raises (and names the content type), JSON array still rejected, HTTP errors still raise. Full suite passes (16).

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 7a10517c-df5c-4e94-8928-d25256b038bd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[rickstaa]

@j0sh I did add tests but we don't have an agreed testing framework setup. I can also remove these for now and we add this later.

[j0sh]

Is this streamable? If not, is that a regression? Eg. #25

[j0sh]

Merged the latest ja/live-runner into this branch.

The response refactor introduced an error-mapping regression: when a JSON response contained bytes that could not be decoded as a valid JSON encoding, json.loads(body) raised UnicodeDecodeError, which escaped directly from both request_json() and call_runner() instead of being reported as the documented LivepeerGatewayError. Both paths now catch UnicodeDecodeError alongside JSONDecodeError and consistently wrap either failure as LivepeerGatewayError.

The buffered response helper is now internal as _request_body, since it is an implementation seam shared only by request_json and call_runner, not a complete public HTTP response API. The seven affected call_runner tests now mock _request_body instead of the no-longer-called request_json. Added coverage verifies that invalid JSON byte encoding raises LivepeerGatewayError through both request_json and call_runner rather than leaking UnicodeDecodeError.

Verification:

• Complete CI-equivalent pytest run with branch coverage: 219 passed