Skip to content

fix: send the content_type partition_via_api accepts - #4489

Open
linhongyu510 wants to merge 1 commit into
Unstructured-IO:mainfrom
linhongyu510:fix/partition-via-api-send-content-type
Open

linhongyu510 wants to merge 1 commit into
Unstructured-IO:mainfrom
linhongyu510:fix/partition-via-api-send-content-type

Conversation

@linhongyu510

@linhongyu510 linhongyu510 commented Sep 17, 2026

Copy link
Copy Markdown
Contributor

Problem

content_type has been the second positional parameter of partition_via_api() since the helper was introduced in #518, and the docstring describes it as:

content_type — A string defining the file content in MIME type

It is never read. Both construction sites pass only content and file_name:

files = shared.Files(content=f.read(), file_name=filename)
...
files = shared.Files(content=file, file_name=metadata_filename)

so the value is silently discarded and the server falls back to sniffing the file name — exactly the situation the parameter exists to override (an extensionless upload, a file whose extension lies about its type, or a stream where only the caller knows the format).

Measured on main (3376cc96) by capturing the request handed to the SDK:

partition_via_api(filename=..., content_type="text/markdown")
# request.partition_parameters.files.content_type -> None

This is not an SDK limitation: shared.Files has a content_type field (['content', 'file_name', 'content_type']). Only the hand-off was missing.

Fix

Populate the field when the caller supplies a value.

When no content_type is given the field is left unset rather than passed as None, so the SDK keeps inferring the type from the file name exactly as before. The parameter is not moved, so existing positional calls bind unchanged.

Tests

  • test_partition_via_api_sends_an_explicit_content_type_for_a_filename
  • test_partition_via_api_sends_an_explicit_content_type_for_a_file
  • test_partition_via_api_leaves_content_type_unset_when_not_given — guards the unchanged default

They assert on the request object actually handed to General.partition, following the method_mock pattern the surrounding tests already use.

Verification

  • 23 pass in test_api.py (20 pre-existing + 3 new).
  • Rollback counter-proof: dropping only the pass-through while keeping the tests fails exactly the 2 "sends an explicit content_type" tests, with the "leaves unset" test still passing — the tests separate the new behavior from the preserved default.
  • No new breakage: across test_api.py, test_md.py, test_text.py and test_json.py the failure set is identical before and after; passing count goes 193 → 196, exactly the 3 added tests. (2 pre-existing failures are environmental and unrelated.)
  • ruff check and ruff format --check clean on both changed files.
  • Checked the 125 open PRs for overlap with partition/api.py: none touches it (feat: add max_page to chunk_by_title and remove multipage_sections #4382 modifies test_api.py only, for chunking).

Independent of #4483 and #4488; all three are cut from main and touch different files.

Review in cubic

`content_type` has been the second positional parameter of
`partition_via_api()` since the helper was introduced in Unstructured-IO#518, and the
docstring describes it as "a string defining the file content in MIME type".
It is never read: both `shared.Files(...)` call sites pass only `content` and
`file_name`, so the value is silently discarded and the server falls back to
sniffing the file name.

`shared.Files` does have a `content_type` field, so nothing was missing on the
SDK side -- only the hand-off. Populate it when the caller supplies a value:

    partition_via_api(filename=..., content_type="text/markdown")
    # before: files.content_type is None
    # after:  files.content_type == "text/markdown"

The field is left unset when no `content_type` is given, so the SDK keeps
inferring the type from the file name exactly as before. The parameter is not
moved, so existing positional calls are unaffected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant