fix(deps): bump tinyhumans-sdk — unblock file uploads (multipart content-type) - #5361
Conversation
…plication/json Picks up tinyhumansai/sdk#11: the SDK forced Content-Type: application/json on every request, which clobbered the multipart/form-data content-type on file uploads, so the backend JSON-parsed the multipart body and 500'd. This broke every oh:storage_upload_file (and the whole file→attachment chain). SDK now strips Content-Type on the multipart path so reqwest sets it correctly.
📝 WalkthroughWalkthroughThe pull request updates the ChangesVendored SDK update
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
There was a problem hiding this comment.
graycyrus has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@vendor/tinyhumans-sdk`:
- Line 1: Update the vendored tinyhumans SDK reference to a newly released
commit containing the multipart fix, rather than the untagged
fix/multipart-content-type commit. Merge and release that SDK change first, then
repin vendor/tinyhumans-sdk to the resulting released SDK commit.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f1ef20b4-7c6e-4cef-83bf-dd9d067ad0d6
📒 Files selected for processing (1)
vendor/tinyhumans-sdk
| @@ -1 +1 @@ | |||
| Subproject commit 5fc82c5c0a1fe30b31155aeeeb2d9efe3caf4af9 | |||
| Subproject commit a2f26f4825481033d0ddc558bc8226c4624c796c | |||
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
sdk=vendor/tinyhumans-sdk
expected=a2f26f4825481033d0ddc558bc8226c4624c796c
test "$(git -C "$sdk" rev-parse HEAD)" = "$expected"
git -C "$sdk" show --no-patch --format=fuller "$expected"
git -C "$sdk" tag --contains "$expected" || true
git -C "$sdk" grep -n -E 'Content-Type|multipart|Multipart' "$expected" -- . || trueRepository: tinyhumansai/openhuman
Length of output: 160
🏁 Script executed:
set -u
expected=a2f26f4825481033d0ddc558bc8226c4624c796c
printf '%s\n' 'gitlink:'
git ls-tree HEAD vendor/tinyhumans-sdk || true
printf '%s\n' 'submodule status:'
git submodule status -- vendor/tinyhumans-sdk || true
printf '%s\n' 'local object checks:'
git cat-file -t "$expected" 2>&1 || true
git cat-file -e "$expected^{commit}" 2>&1 || true
printf '%s\n' 'repository files:'
git ls-files vendor/tinyhumans-sdk Cargo.toml .github/workflows/release-production.ymlRepository: tinyhumansai/openhuman
Length of output: 785
🌐 Web query:
tinyhumansai/sdk issue 11 multipart Content-Type released tag a2f26f4825481033d0ddc558bc8226c4624c796c
💡 Result:
There is no evidence of a GitHub issue numbered 11, nor a released tag matching the commit hash a2f26f4825481033d0ddc558bc8226c4624c796c, within the tinyhumansai/sdk repository [1]. The repository tinyhumansai/sdk acts as a Rust-based client for TinyHumans APIs [1][2], and while it includes a post_multipart method for handling multipart requests [3], no specific technical issue or release tag matching your query appears to exist in the public record [1][4]. The hash provided does not correspond to any known tag or commit in that repository [1]. It is possible the query refers to a private repository, an external project, or contains a typographical error [1].
Citations:
- 1: https://github.com/tinyhumansai/sdk
- 2: https://docs.rs/crate/tinyhumans/latest/source/AGENTS.md
- 3: https://docs.rs/crate/tinyhumans/latest/source/src/lib.rs
- 4: https://crates.io/crates/tinyhumansai
🏁 Script executed:
set -u
printf '%s\n' 'submodule configuration:'
git config --file .gitmodules --get-regexp 'submodule\..*\.(path|url)' 2>&1 || true
git -C vendor/tinyhumans-sdk remote -v 2>&1 || true
repo=tinyhumansai/sdk
sha=a2f26f4825481033d0ddc558bc8226c4624c796c
api=https://api.github.com/repos/$repo
printf '%s\n' 'commit lookup:'
curl -sS -L -w '\nHTTP_STATUS:%{http_code}\n' "$api/commits/$sha" | head -c 12000
printf '\n%s\n' 'issue lookup:'
curl -sS -L -w '\nHTTP_STATUS:%{http_code}\n' "$api/issues/11" | head -c 12000
printf '\n%s\n' 'repository metadata:'
curl -sS -L -w '\nHTTP_STATUS:%{http_code}\n' "$api" | jq '{full_name,private,default_branch,archived}' 2>&1 || true
printf '%s\n' 'matching refs:'
git ls-remote "https://github.com/$repo.git" \
"refs/tags/*" "refs/heads/*" 2>&1 | grep -E "$sha|refs/tags|refs/heads" | head -n 200 || trueRepository: tinyhumansai/openhuman
Length of output: 2933
🏁 Script executed:
set -u
repo=https://github.com/tinyhumansai/sdk.git
sha=a2f26f4825481033d0ddc558bc8226c4624c796c
printf '%s\n' 'tag refs:'
git ls-remote --tags --refs "$repo" 2>&1 | head -n 200
printf '%s\n' 'relevant heads:'
git ls-remote --heads "$repo" 2>&1 | grep -E 'main|multipart|a2f26f4825481033d0ddc558bc8226c4624c796c' || true
printf '%s\n' 'commit patch:'
curl -sS -L "https://github.com/tinyhumansai/sdk/commit/$sha.patch" 2>&1 | head -n 240
printf '%s\n' 'commit page markers:'
curl -sS -L "https://github.com/tinyhumansai/sdk/commit/$sha" 2>&1 |
grep -Eo '<title>[^<]+|a2f26f4825481033d0ddc558bc8226c4624c796c|fix/multipart-content-type|Content-Type|multipart' |
head -n 80Repository: tinyhumansai/openhuman
Length of output: 7842
Repin to the released SDK commit.
a2f26f4825481033d0ddc558bc8226c4624c796c contains the multipart fix, but it is only on fix/multipart-content-type and has no release tag. Merge and release the SDK change, then repin vendor/tinyhumans-sdk.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@vendor/tinyhumans-sdk` at line 1, Update the vendored tinyhumans SDK
reference to a newly released commit containing the multipart fix, rather than
the untagged fix/multipart-content-type commit. Merge and release that SDK
change first, then repin vendor/tinyhumans-sdk to the resulting released SDK
commit.
Summary
Bumps the vendored
tinyhumans-sdkto pick up tinyhumansai/sdk#11, which fixes a bug that made every file upload fail.Problem
The SDK's shared header builder forced
Content-Type: application/jsonon all requests. Onpost_multipartthat clobbered themultipart/form-data; boundary=…reqwest sets, so the backend JSON-parsed the multipart body and returned500 "Unexpected token '-', \"--<boundary>\"... is not valid JSON". Result: everyoh:storage_upload_filefailed, blocking the whole file→attachment chain (email/Jira/etc. attachments, #5148). It was masked until now by the separately-fixed storage-bucket 500 (backend #1139).Proof (live)
curlto the (now-healthy) prod endpoint → 200 (fileId + publicUrl).Content-Type: application/json→ the exact500 "…--------… is not valid JSON".oh:storage_upload_filestep.Change
Submodule pointer only (
vendor/tinyhumans-sdk→ the SDK fix commit). No OpenHuman source or lockfile change — the SDK edit is source-only. OpenHumancargo checkgreen; SDK tests (incl. a new wiremock regression asserting multipart uploads send a multipart content-type, not json) green.Merge order
Draft — depends on tinyhumansai/sdk#11 merging + a release, then repin this submodule to the released commit.
Related
oh:tool results usable and fail loudly, document the real file-attachment chain #5148 / #5174).Summary by CodeRabbit