Repository navigation
openapi: sequential media types derive the wrong item type #630
Description
Problem
openapi: 3.2.0
…
responses:
"200":
description: ok
content:
application/jsonl: {schema: {type: array, items: {$ref: '#/components/schemas/Event'}}}The operation streams with responseStream.events set to the anonymous array, not Event. Each frame of a JSON Lines stream is one Event; the schema describes the sequence as a whole.
application/json: {itemSchema: {$ref: '#/components/schemas/Event'}}itemSchema on application/json, which isn't a sequential media type, becomes a stream with no diagnostic.
Expected
- For a sequential media type whose
schemais an array, the item type is the array'sitems. itemSchemaon a media type that isn't sequential draws a warning.
Activity
docs(emitter-design): settle the responses beside the primary
chore(skills): correct a Why that a final PR falsified
OmarAlJarrah commentedon Oct 30, 2026
#1167 landed with this open, and landing this changes no emitter plan (
docs/emitters/plan/streams.md, main @7e1e3fc8). On a side framed by its media type,Elementalready reads theElemof a contentTypewhose root is a list, ahead ofStreamDetail.Events, so one frame's type is the same whetherEventsnames the list or itsElem.The second expected item, a warning for
itemSchemaon a media type that isn't sequential, is the compiler's and #1167 doesn't touch it.OmarAlJarrah commentedon Nov 1, 2026
A constraint on the first bullet, found while working on #1191: the list can't be read during the operation walk.
applyStreamingruns mid-walk, and a$reftarget need not be in the registry yet, since a target another document holds is built whenFinishfulfils its promise, so a mid-walk read would follow declaration order. Reading it from a settlement is the shape that works, and that has to move the comparison inclassifyStreamwith it: whether two contents name the same element depends on the resolvedElem, soambiguouscan't be decided before the registry is whole.No consumer is waiting on this:
docs/emitters/plan/streams.mdalready reads a list'sElemfrom the content'sType, so the plan's element is right either way, and this only changes whatEventsstates.