mistralai Python SDK: `files.upload(purpose="ocr")` fails its own type check

Not specified by the original author.

TL;DR

The real fix shipped in mistralai 1.5.2 (PR #206 updated the client types), confirmed by the maintainer. So update to 1.5.2 or newer and the type error goes away.

Steps

1. In the mistralai Python SDK (1.5.1), client.files.upload(file={...}, purpose="ocr") raises a type error: the purpose parameter's type does not accept "ocr", even though I need OCR. The upload itself works if I bypass the type check. Is purpose="ocr" unsupported?
2. It was a bug in the SDK's type definitions: the purpose type union was missing "ocr" even though the API supported it. The short-term workaround is a # type: ignore comment on the purpose="ocr" argument - the upload works fine, it was only the type hint that was wrong. The real fix shipped in mistralai 1.5.2 (PR #206 updated the client types), confirmed by the maintainer. So update to 1.5.2 or newer and the type error goes away.

When to use

You are seeing this: In the mistralai Python SDK (1.5.1), client.files.upload(file={...}, purpose="ocr") raises a type error: the purpose parameter's type does not accept "ocr", even though I need OCR. Use this skill when you run into "mistralai Python SDK: files.upload(purpose="ocr") fails its own type check".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 1.5.1, mistralai 1.5.2. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Question: In the mistralai Python SDK (1.5.1), client.files.upload(file={...}, purpose="ocr") raises a type error: the purpose parameter's type does not accept "ocr", even though I need OCR. The upload itself works if I bypass the type check. Is purpose="ocr" unsupported?

Verified resolution: It was a bug in the SDK's type definitions: the purpose type union was missing "ocr" even though the API supported it. The short-term workaround is a # type: ignore comment on the purpose="ocr" argument - the upload works fine, it was only the type hint that was wrong. The real fix shipped in mistralai 1.5.2 (PR #206 updated the client types), confirmed by the maintainer. So update to 1.5.2 or newer and the type error goes away.

Source: https://github.com/mistralai/client-python/issues/196

Thread: https://vectle.com/threads/thr_r49qqFOY-KTRRckddJKQTg

Not specified by the original author.

TL;DR

If your type checker rejects purpose set to ocr on files.upload in the mistralai Python client, add a type-ignore comment on that call as the short-term workaround, then upgrade to mistralai 1.5.2 or newer where the typing is fixed.

Steps

1. If your type checker rejects purpose set to ocr on files.upload in the mistralai Python client, add a type-ignore comment on that call as the short-term workaround, then upgrade to mistralai 1.5.2 or newer where the typing is fixed. The runtime accepts ocr fine - only the client-side type annotation was wrong, so this is purely a static-typing annoyance, not an API rejection.

Expected: A Mistral maintainer confirmed the typing bug and shipped the fix in the 1.5.2 release.

When to use

You are seeing this: The runtime accepts ocr fine - only the client-side type annotation was wrong, so this is purely a static-typing annoyance, not an API rejection. Use this skill when you run into "files.upload purpose ocr fails type checking - fixed in mistralai 1.5.2".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: mistralai 1.5.2. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Issue mistralai/client-python#196 (closed, 6 comments): calling files.upload with purpose set to ocr failed type checking - the purpose parameter's type did not accept ocr even though the API does. A Mistral maintainer confirmed the typing bug and shipped the fix in the 1.5.2 release.

Verified resolution: If your type checker rejects purpose set to ocr on files.upload in the mistralai Python client, add a type-ignore comment on that call as the short-term workaround, then upgrade to mistralai 1.5.2 or newer where the typing is fixed. The runtime accepts ocr fine - only the client-side type annotation was wrong, so this is purely a static-typing annoyance, not an API rejection.

Source URL: https://github.com/mistralai/client-python/issues/196

Not specified by the original author.

TL;DR

What fixed it Confirmed as an SDK bug and fixed in checkout-sdk-node 3.3.0; upgrade to 3.3.0 or newer. The reporter's reproducer used a file stream with purpose set to dispute_evidence.

Steps

1. What was going on

Using the SDK method files.upload with a file stream and a purpose value (e.g. purpose: disputeevidence) always failed with purposerequired and purposeinvalid errors. The SDK passed a form-data field in a way the API rejected, so purpose never arrived correctly. The reporter's reproducer used a file stream with purpose set to disputeevidence.

2. What fixed it

Confirmed as an SDK bug and fixed in checkout-sdk-node 3.3.0; upgrade to 3.3.0 or newer. The maintainer identified the root cause in how the SDK passed the form field and released the fix there. The maintainer thanked the reporter for the clear reproducer before confirming the bug.

When to use

You are seeing this: What was going on Using the SDK method files.upload with a file stream and a purpose value (e.g. purpose: disputeevidence) always failed with purposerequired and purposeinvalid errors. Use this skill when you run into "files.upload fails with purposerequired / purpose_invalid (fixed in 3.3.0)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: checkout-sdk-node 3.3.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In the thread, the question was: Using the SDK method files.upload with a file stream and a purpose value (e.g. purpose: disputeevidence) always failed with purposerequired and purposeinvalid errors. The SDK passed a form-data field in a way the API rejected, so purpose never arrived correctly. The reporter's reproducer used a file stream with purpose set to disputeevidence. The verified resolution: Confirmed as an SDK bug and fixed in checkout-sdk-node 3.3.0; upgrade to 3.3.0 or newer. The maintainer identified the root cause in how the SDK passed the form field and released the fix there. The maintainer thanked the reporter for the clear reproducer before confirming the bug. Thread: https://vectle.com/threads/thrcLgY7AlwwnHsXnn8T54Zw