fix(python): enforce size_limit_bytes in multipart ingest path#2935
Draft
KiewanVillatel wants to merge 1 commit into
Draft
fix(python): enforce size_limit_bytes in multipart ingest path#2935KiewanVillatel wants to merge 1 commit into
KiewanVillatel wants to merge 1 commit into
Conversation
Mirrors the batch-splitting logic from _batch_ingest_run_ops into _multipart_ingest_ops so that accumulated multipart payloads are split into multiple requests when they exceed size_limit_bytes. Previously all ops drained in a single cycle were joined into one request regardless of size, causing OOM crashes when large tool outputs were bundled together (e.g. 194 MB POST → repeated retries at 3 GB RSS). Adds _multipart_part_size helper to estimate the byte size of a MultipartPartsAndContext, and updates test_batch_ingest_run_splits_large_batches to reflect that the multipart path now splits at the same threshold. Fixes LSDK-207. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
| finally: | ||
| _close_files(list(opened_files_dict.values())) | ||
| except ls_utils.LangSmithNotFoundError: | ||
| # Fallback to batch ingest if multipart endpoint returns 404 |
Contributor
There was a problem hiding this comment.
Do we need that?
| for _, (_, data, _, _) in part.parts: | ||
| if isinstance(data, bytes): | ||
| total += len(data) | ||
| elif isinstance(data, BufferedReader): |
Contributor
There was a problem hiding this comment.
Is it checking for attachments? I am not sure we should as attachements have a higher size limit.
The multipart endpoint shouldn't error on a small JSON payload with large attachments.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
_multipart_ingest_opsnow splits ops into multiple requests when the accumulated payload would exceedsize_limit_bytes, mirroring the batch-splitting logic that already existed in_batch_ingest_run_ops_multipart_part_sizehelper in_multipart.pyto estimate the byte size of aMultipartPartsAndContext(useslen(data)for bytes parts,os.fstatfor file attachments)_max_batch_size_bytes> serverbatch_ingest_config.size_limit_bytes>_SIZE_LIMIT_BYTES(20 MB default)batch_size > 0before splitting, preserving current behavior for oversized individual ops)Linear
https://linear.app/langchain/issue/LSDK-207/multipart-ingest-path-has-no-batch-size-enforcement-allowing
Test Plan
test_multipart_ingest_ops_splits_by_size— calls_multipart_ingest_opswith 3 × 500-byte ops against a 600-byte limit; asserts 3 separate_send_multipart_reqcallstest_multipart_ingest_ops_no_split_when_within_limit— 2 × 100-byte ops against 10 KB limit; asserts 1_send_multipart_reqcalltest_batch_ingest_run_splits_large_batches[True-*]— updated expected request count to use the same formula as theFalse(non-multipart) parameterized variant, since both paths now enforce the same limitRelease Note
Fixed an issue where the multipart ingest path could send arbitrarily large requests when many runs with large payloads were batched together, causing OOM crashes in high-throughput environments.