Repository navigation
perf(cli,mcp): transcribe long recordings without loading the whole file into memory - #538
Merged
Merged
Conversation
…in memory fetch with a FormData builds the whole multipart body in memory before it sends a byte, even for a Bun.file part, so akou transcribe of a long recording grew by more than the file. The client now sends every form as a streamed multipart body with a computed Content-Length.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 1 minute. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
The parent's Subprocess.resourceUsage() gave the same peak for a 1 KiB and a 256 MiB FormData upload in the full suite on Linux, so the positive control saw no growth there and the streamed-upload assertion could not fail. Each child now writes its own peak on exit through a preload, and a peak below 8 MiB fails as no measurement.
On Linux execve keeps the larger of the spawning process's resident size and the child's in maxRSS, so in the full suite every child reported the test runner's size and a 1 KiB and a 256 MiB upload read the same peak. The preload now reads VmHWM from /proc/self/status there, and the growth assertions compare the two peaks so a failure prints both.
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.
Problem
akou transcribeandakou dictate FILEread the whole file into memory before they sent a byte. A 2 GB recording made the CLI grow by 2 GB or more. Swapping inBun.filedoes not help:fetchwith aFormDatabody builds the whole multipart body in memory first. We measured this on Bun 1.4.2 with a 256 MiB file. Transcribe grew by 537 MB and dictate by 806 MB.akou_transcribein the MCP server has the same problem, although its comment said the file was never held in memory whole.Fix
The client now sends every form as its own streamed multipart body. Each file part is read from disk as it goes out. The body still declares its Content-Length, so a server still refuses an upload over
server.max_upload_mbbefore it reads any of it. If a file changes size during the upload, the request fails. It does not send a body of the wrong length. The CLI still checks that the file exists and can be read before it sends anything. The MCP comment now says what the code does.There is one Bun detail. A
Bun.filein aFormDatakeeps its full path as its name, andentries()drops the filename given toappend. So the client names the file itself and sends only the last part of the path, never the folder.Testing
[UPL-1]in docs/TRAPS.md, tested intests/upload-stream.e2e.test.ts.FormDatawith plainfetchgrows past the limit.check:staticpasses. The jobs, dictation, MCP, remote and multipart suites pass (180 tests).