#98 - generate msg-pack

[tomsontom]

No description provided.

[tomsontom]

Automated review (Claude)

Reviewed the diff for #98 (adding msgpack representations to the generated OpenAPI spec). Small change, two findings:

1. Streaming operations' application/vnd.msgpack schema was wrong — fixed

open-api/service.ts:105 documented application/vnd.msgpack for a streaming operation with the array-wrapped schema ({type: 'array', items: {...}}) — the same schema used for application/json. But Accept: application/vnd.msgpack on a streaming operation actually negotiates the same per-element streaming format as application/x-ndjson (confirmed via computeStreamResponseContentType in resource.ts, which routes msgpack through the same negotiated-streaming path — there's no msgpack equivalent of the AsJsonArray complete-array sibling method, only application/json gets that). Verified in the generated openapi.json: streamRecord's msgpack entry claimed a full array, identical to the JSON entry, while application/x-ndjson two lines above it already correctly used the unwrapped element schema for the same reason.

Fixed: msgpack now uses schema.items for streaming operations, matching the x-ndjson treatment, while non-streaming array operations keep the full array schema for msgpack (correct there, since msgpack really does encode the whole array as one value in that case). Verified in generated output for both a streaming op (streamRecord, now unwrapped) and a non-streaming array op (queryList, still array-wrapped, unaffected).

2. contentTypeEncodings: [] handled inconsistently with the rest of the codebase (not fixed, flagging only)

This file only checks artifactConfig.contentTypeEncodings === undefined. Three other generators (java-rest-client-jdk/client.ts, java-server-jakarta-ws/resource.ts, java-model-json/json-utils.ts) also treat an empty array the same as undefined, defaulting to application/json. Here, an empty array would instead silently produce content: {} — no documented representations at all — for every operation, while the actual generated server/client for the same project would still default to JSON. Currently untested since the sample spec always sets both encodings explicitly, so this is a dormant edge case rather than a live bug.

Not part of this PR, flagging for awareness only

File/blob download operations (downloadFile, variant === 'stream') are documented with application/json/application/vnd.msgpack and a {type: 'string', format: 'binary'} schema, but their actual runtime Content-Type is the file's own dynamic mime type (_RestUtils.toStreamResponse), unrelated to json/msgpack negotiation. This predates #99 for the application/json entry; this PR's new msgpack line just adds a second instance of the same pre-existing inaccuracy. Worth a follow-up issue if you want it tracked, not something to fix here.

---

Generated by an automated review pass (Claude Code); please verify before acting on any finding.