[dinwwwh]

Requested by dinwwwh · project thread

What

Some real 3.1 documents mark a JSON or XML body schema with its media type:

{ "allOf": [{ "$ref": "#/components/schemas/AbuseTicketCreate" }, { "description": "..." }], "contentMediaType": "application/json" }

In 2020-12, contentMediaType only applies to strings, so this is just the object. The schema has no type, so finishSchema gave it format: "binary" and type: "string". In 3.0 nothing matched that (a value had to be a string and the object at once), and tools read the body as a file upload. A bare { $ref, contentMediaType } went the same way.

Change

An untyped schema gains format and type: "string" from the content keywords only when it has none of $ref, allOf, anyOf, oneOf, properties, items or prefixItems. Otherwise the content keywords are just dropped, as they already were beside type: "object". Bare file parts such as { contentMediaType: "image/png" } keep becoming a binary string. The README row for contentEncoding and contentMediaType says so; the Limitations line on untyped schemas gaining type: "string" still holds as written.

Checks

• New test covers each of the seven keywords; it fails on main. pnpm run check, pnpm test pass, coverage stays 100%, no snapshot changes.
• Itential's GoDaddy adapter (@itentialopensource/adapter-godaddy 1.0.12, report/adapter-openapi.yaml, 3.1.0): format: binary beside allOf goes from 606 to 0, and request bodies that were binary strings from 21 to 0. The 594 left are bare { contentMediaType: "application/javascript" } responses, which stay as they were.
• Perf: the new check runs only when a schema has content keywords. GoDaddy median in one process with gc, interleaved, 100 rounds: 7.28 ms before, 7.06 ms after (noise).

🤖 Generated with Claude Code

https://claude.ai/code/session_01VVaw7RSkvUE8NjM89RakVV

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed]

Merging this PR will not alter performance

✅ 21 untouched benchmarks

---

_{Comparing claude/project-thread-o4731q (11d886a) with main (3676052)}

[pullfrog]

ℹ️ No critical issues — the core fix is correct. One same-class omission noted inline.

Reviewed changes

• Predicate for untyped content-keyword schemas — hasSubschemas (v3.1-to-v3.0.ts:1090) gates the format/type: "string" injection on $ref, allOf, anyOf, oneOf, properties, items; the rest of the content-keyword handling is unchanged.
• README row — documents that the keywords are dropped (rather than turned into a binary string) when the schema holds subschemas.
• Test — covers all six keywords, plus the bare { $ref, contentMediaType } case.

The change is correct and well-targeted: the content keywords are string-only annotations in 2020-12, so forcing type: "string" on a schema that already describes an object/array via subschemas both rejected values the source accepted and made 3.0 tools read the body as a file upload. I ran vitest run packages/downgrader/tests/v3.1-to-v3.0.test.ts (113 passing) and separately probed the predicate.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

Correction to my review above: the inline suggestion attached to my first review (packages/downgrader/src/v3.1-to-v3.0.ts) was garbled — it contained stray placeholder functions and would break the file. Please ignore that suggestion block entirely. The intended, corrected change replaces the two lines at v3.1-to-v3.0.ts:1098-1099 with:

    schema.properties !== undefined ||
    schema.items !== undefined ||
    schema.prefixItems !== undefined

Rationale (unchanged): hasSubschemas omits prefixItems, so an untyped schema such as { prefixItems: [{ type: "string" }], contentMediaType: "application/json" } still gains format: "binary" + type: "string". Since convertTuple folds prefixItems into items in the output, this is the same failure mode the PR fixes — the output ends up { items, format: "binary", type: "string" }, rejecting the arrays the source accepted. patternProperties/not are same-class omissions, but prefixItems is the direct analog to the already-listed items.

Otherwise the fix is sound and the tests pass (vitest run packages/downgrader/tests/v3.1-to-v3.0.test.ts, 113 passing).

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes

• prefixItems added to the subschema predicate — hasSubschemas (v3.1-to-v3.0.ts:1092) now also returns true for prefixItems, so an untyped schema with a content keyword and a tuple keeps its converted items instead of being forced to type: "string".
• Test — covers { prefixItems: [...], contentMediaType } yielding { items: {} }, completing the set of keywords the earlier review noted as missing.
• README row — now lists prefixItems among the keywords that suppress the type: "string" injection.

This delta directly addresses the one prior inline thread (prefixItems omitted from hasSubschemas); the author's fix is correct — the tuple is an array, not a binary string, so dropping the content keywords is the right outcome. The full diff remains well-targeted, and the change is only consulted for untyped schemas. Ran vitest run packages/downgrader/tests/v3.1-to-v3.0.test.ts (113 passing, including the new case).

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}