Conversation
Introduce an in-process UploadNormalizationLimiter to bound concurrent PDF/image normalization (Math.max(2, availableParallelism())). Start the original blob write concurrently with normalization to overlap I/O and CPU, await the original write before writing the normalized blob, and release the decoded upload buffer early to reduce peak memory. Move expensive pdf-lib parsing into normalizeToPdf (validateForUpload now does a cheap magic-byte probe for PDFs), add robust parse/error handling, and generate thumbnails from the normalized PDF bytes. Wire the limiter into the Document module/service, add unit tests for the limiter and updated upload behavior/order, and update documentation to describe the upload memory/concurrency model and API implications.
kmandryk
requested review from
NoorChasib,
alex-struk,
antsand and
dbarkowsky
as code owners
June 9, 2026 23:17
dbarkowsky
requested changes
Jun 11, 2026
dbarkowsky
left a comment
dbarkowsky
left a comment
Collaborator
There was a problem hiding this comment.
Just requesting docs on the Semaphore file.
The other comment is just a hypothetical unless it's something you want to address.
Introduce an in-process Semaphore and UploadNormalizationLimiter to cap concurrent PDF/image normalization per process (uses availableParallelism/cpus and floors to at least 2). Semaphore enqueues waiters FIFO and exposes a run() helper. DocumentService now awaits the original write before recording a conversion failure and intentionally retains the original blob on normalization failure so clients can still download the upload. Update docs to explain that normalized_file_path is absent on failure but file_path remains valid.
dbarkowsky
approved these changes
Jun 16, 2026
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
2 participants
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.
Introduce an in-process UploadNormalizationLimiter to bound concurrent PDF/image normalization (Math.max(2, availableParallelism())). Start the original blob write concurrently with normalization to overlap I/O and CPU, await the original write before writing the normalized blob, and release the decoded upload buffer early to reduce peak memory. Move expensive pdf-lib parsing into normalizeToPdf (validateForUpload now does a cheap magic-byte probe for PDFs), add robust parse/error handling, and generate thumbnails from the normalized PDF bytes. Wire the limiter into the Document module/service, add unit tests for the limiter and updated upload behavior/order, and update documentation to describe the upload memory/concurrency model and API implications.
Summary
address upload-ocr bottleneck
AI-1240
Testing
Re-run payload-sizes large × 5 VU on the load-test instance to validate OOM/failure-rate acceptance criteria