After an OpenAPI tooling upgrade, regenerating a TypeScript client with oazapfts silently flips every multipart file-upload field from Blob/Blob[] to string, breaking all existing upload callsites. tsc/svelte-check then fails with "Type 'Blob' is not assignable to type 'string'" (and "Type 'File' is not assignable to type 'string'") across upload_file, import_file, files fields. The regen looked like it only ADDED new endpoints in the diff, but it also changed the TYPES of unrelated existing upload fields — easy to miss and easy to wrongly attribute to your own changes.
Root cause: FastAPI >= ~0.129.1 emits OpenAPI 3.1, where binary upload fields are described with type: string + contentMediaType: application/octet-stream (and/or contentEncoding) instead of OpenAPI 3.0's format: binary. oazapfts maps format: binary -> Blob, but a plain string with no binary format -> string. So the schema-shape change (not oazapfts itself) is what flips the generated types.
Fix: post-process the OpenAPI schema BEFORE running oazapfts — walk all schema properties and, where a field carries contentMediaType/contentEncoding marking it binary, set format: 'binary' (and drop/keep type:string) so oazapfts emits Blob again. Pseudo: def fixup(schema): for each property with contentMediaType: property['format']='binary'. Regenerate, then grep the SDK to confirm upload_file: Blob (not string) and run tsc/svelte-check.
Gotcha when diagnosing: an SDK regen diff that 'only adds endpoints' can still silently retype existing multipart fields; if a whole-project typecheck suddenly fails on upload sites you didn't touch, suspect the schema/tooling, not your feature. Pin/verify the FastAPI<->oazapfts pairing and add the contentMediaType fixup to the SDK build step.