⚡ Bolt: Prevent Call Stack Exceeded on large array push#402
⚡ Bolt: Prevent Call Stack Exceeded on large array push#402AhmmedSamier wants to merge 1 commit intomasterfrom
Conversation
Replaces the use of the array spread operator (`push(...items)`) with a manual `for` loop in performance-critical paths dealing with potentially unbounded arrays (e.g., search results, file discovery). This safely appends items regardless of array size and prevents the V8 engine from throwing a `RangeError: Maximum call stack size exceeded` when processing large workspaces. Co-authored-by: AhmmedSamier <17784876+AhmmedSamier@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
📝 WalkthroughWalkthroughApplies a documented performance safeguard across the codebase: replaces spread-based array concatenation ( Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Review rate limit: 0/1 reviews remaining, refill in 60 minutes.Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
language-server/src/core/search-engine.ts (1)
285-303:⚠️ Potential issue | 🟠 MajorSnapshot
items.lengthbefore loop iterations to prevent unbounded growth if a caller passesthis.items.The
addItemsmethod is public and could theoretically be called with the same array instance asthis.items. The current implementation re-evaluatesitems.lengthon each iteration, which would cause an infinite loop ifitems === this.itemsdue to thepush()operations in the first loop growing the array.🔧 Fix
async addItems(items: SearchableItem[]): Promise<void> { this.invalidateDerivedCaches(); + const itemsLength = items.length; // Pre-calculate start index for new items const startIndex = this.items.length; - const requiredSize = startIndex + items.length; + const requiredSize = startIndex + itemsLength; @@ - for (let i = 0; i < items.length; i++) { + for (let i = 0; i < itemsLength; i++) { this.items.push(items[i]); } const CHUNK_SIZE = 500; - for (let i = 0; i < items.length; i += CHUNK_SIZE) { - const end = Math.min(i + CHUNK_SIZE, items.length); + for (let i = 0; i < itemsLength; i += CHUNK_SIZE) { + const end = Math.min(i + CHUNK_SIZE, itemsLength); for (let j = i; j < end; j++) { this.processAddedItem(items[j], startIndex + j); } // Yield to main thread for responsiveness - if (end < items.length) { + if (end < itemsLength) { await new Promise((resolve) => setTimeout(resolve, 0)); } } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@language-server/src/core/search-engine.ts` around lines 285 - 303, The addItems method currently re-reads items.length each loop which can cause an infinite loop if the caller passed this.items; snapshot the incoming array length into a local const (e.g., const originalLen = items.length) and use originalLen in the initial push loop and in the CHUNK_SIZE chunking loop (compute end = Math.min(i + CHUNK_SIZE, originalLen)), keeping references to processAddedItem and startIndex unchanged so indices remain correct; this prevents unbounded growth when items === this.items.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@language-server/src/core/search-engine.ts`:
- Around line 285-303: The addItems method currently re-reads items.length each
loop which can cause an infinite loop if the caller passed this.items; snapshot
the incoming array length into a local const (e.g., const originalLen =
items.length) and use originalLen in the initial push loop and in the CHUNK_SIZE
chunking loop (compute end = Math.min(i + CHUNK_SIZE, originalLen)), keeping
references to processAddedItem and startIndex unchanged so indices remain
correct; this prevents unbounded growth when items === this.items.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1f09f938-81cb-40ba-809c-286d7830b2d4
📒 Files selected for processing (5)
.jules/bolt.mdlanguage-server/src/core/ripgrep-service.tslanguage-server/src/core/search-engine.tslanguage-server/src/core/workspace-indexer.tslanguage-server/src/indexer-client.ts
1 participant
💡 What: Replaced instances of
array.push(...items)with a manualforloop across core search and indexer logic.🎯 Why: Using the spread operator on very large arrays passes each element as an argument to the function, which can exceed V8's maximum call stack size limit (typically ~65k items), leading to runtime crashes when parsing or searching massive workspaces.
📊 Impact: Completely eliminates the risk of
RangeError: Maximum call stack size exceededin file discovery and search aggregation paths, improving robustness for large enterprise codebases without sacrificing performance.🔬 Measurement: Verified via successful test runs (no regressions) and code inspection. Performance is identical or slightly improved due to less memory allocation overhead compared to spreading large iterables.
PR created automatically by Jules for task 8320727021902025896 started by @AhmmedSamier
Summary by CodeRabbit
Bug Fixes
Documentation