fix(snapshots): Chunk image uploads to avoid fd exhaustion and 413 errors

[NicoHinderling]

Uploading hundreds of images via build snapshots fails in two ways:

1. Too many open files (EMFILE): All image file handles are opened upfront and held until the batch send completes. This exceeds OS file descriptor limits (~256 on macOS, ~1024 on Linux).
2. 413 Payload Too Large: The objectstore client batches up to 1000 operations into a single HTTP request. With hundreds of images the multipart body exceeds the server's size limit.

Both failures were confirmed with a real 753-image upload. 734 out of 753 images failed with 413 errors.

This PR splits upload_images() into two phases:

• Phase 1 (pre-process): Iterate all images to detect filename collisions, compute SHA-256 hashes, read sidecar metadata, and build manifest entries — without opening any files for upload.
• Phase 2 (chunked upload): Upload in batches of 100 images. For each batch, open files, build a fresh session.many() builder, and send. This bounds both open file descriptors and HTTP request payload size.

Also includes minor code quality improvements: simplified scope extraction, iterator-based collision formatting, and removal of redundant bindings.

[NicoHinderling]

open to your guys' thoughts, but through some testing, seems to be a good number

[jan-auer]

Once these two fixes are available, the custom batching can be removed again. Objectstore client batches internally:

• feat(client): Add put_path for lazy file descriptor opening objectstore#415
• https://github.com/getsentry/ops/pull/19909

[NicoHinderling]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(snapshots): Chunk image uploads to avoid fd exhaustion and 413 errors #3249 👈 (View in Graphite)
• perf(snapshots): Parallelize image hashing with rayon #3250
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[NicoHinderling]

synced offline with @lcian , putting in draft mode since while fd limit is real, we on client side apparently shouldn't be handling the batching

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Upload error messages lose cause chain detail

Low Severity

The old code wrapped each upload error in anyhow::Error::new(error) before formatting with {error:#}, which displays the full error cause chain (e.g., "request failed: 413 Payload Too Large"). The new code removed this wrapping, so {error:#} on the raw error type likely only shows the top-level message since most non-anyhow types ignore the alternate flag. This loses valuable diagnostic context, especially for the 413 errors this PR aims to fix. Computing error_count via .len() before the loop would allow iterating by value and preserving the anyhow wrapping.

 

[jan-auer]

Updated objectstore-client to 0.1.4. The fd limit is resolved and we also limit requests to 100MB internally now in addition to the preexisting 1000 ops / request limit. Upload with a provided sample succeeds now.