[DMOAbove]

Fixes #1841

Problem

Since 13.5.0 (1ed598b), type: string, format: byte is generated as Blob.

In OpenAPI, byte means base64-encoded characters, and raw bytes are format: binary (OpenAPI 3.0 Data Types).
In a JSON body these values are plain strings. For example, ASP.NET serialises byte[] properties such as concurrency tokens (rowVersion) as base64 strings. With Blob, the generated type no longer matches the runtime value, so a value read from one response can't be sent back in the next request without a cast.

Solution

• src/configuration.ts: byte maps to string again, as in 13.4.x and earlier.
• src/schema-routes/schema-routes.ts: the binary-produces response alias (c4b02db) got its
  Blob type from a synthetic { type: "string", format: "byte" } schema, so changing the
  mapping alone would have turned those aliases into string. It now uses format: "binary"
  and sets the alias content to Blob directly. Binary downloads are still typed as Blob.
  Only their JSDoc changes, from @format byte to @format binary, which describes them
  more accurately.

Verification

• New regression test tests/spec/issue-1841: a JSON body with rowVersion: format byte
  generates rowVersion: string, and format: binary still generates File. It fails
  without this change.
• Updated snapshots in binary-produces, binary-produces-base-path and
  binary-produces-base-path-with-extracts. format: byte properties change from Blob to
  string, GetXxxExportData aliases stay Blob, and route return types are unchanged.
• Changeset added (patch).

---

Summary by cubic

Fixes #1841. Since 13.5.0, format: byte was generated as Blob, but per the OpenAPI spec it is base64-encoded text carried as a JSON string; raw bytes are format: binary. Properties like ASP.NET byte[] concurrency tokens are now generated as string again, matching the runtime value so they can be sent back in a request without a cast.

• Binary download response aliases (e.g., GetXxxExportData) stay typed as Blob, now built from a format: binary schema with the alias content set directly; their JSDoc changes from @format byte to @format binary.
• Adds a regression test covering format: byte → string and format: binary → File, and updates affected snapshots.

^{Written for commit 49a8fee. Summary will update on new commits.}

[changeset-bot]

🦋 Changeset detected

Latest commit: 49a8fee

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
swagger-typescript-api	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cubic-dev-ai]

No issues found across 9 files

_{View guided diff | Re-trigger cubic}

[js2me]

This is breaking change. And if developer occurs with same problem then it's just changes using codegen config

      byte: () => this.Ts.Keyword.String,

All my cases with byte requires Blob

[DMOAbove]

Thanks, the primitiveTypeConstructs override works for us, so we'll use that and drop our version pin.

For the record, I'd still question the default. In OpenAPI, format: byte means base64-encoded text inside JSON. For example, a C# byte[] such as a row version is serialised as "AAAAAAAAB9E=". Raw bytes are format: binary, which is already mapped to File. In a JSON body the runtime value is always a string, never a Blob, so the generated type doesn't match what axios/fetch actually return.

If your cases need Blob, it may be worth checking whether those specs mark binary payloads as byte when they should use binary. A middle ground could be to keep string for application/json and use Blob only for multipart or octet-stream content.

Either way, since this changed the generated output in a minor release (13.4.0), a "breaking" note in the changelog, with the override snippet, would save others the debugging time.