OPDATA-6745: Fix memory leak in Requester#805
Merged
Merged
Conversation
Contributor
NPM Publishing labels 🏷️🟢 This PR has valid version labels and will cause a |
53046de to
4d26405
Compare
mmcallister-cll
approved these changes
Jun 5, 2026
Contributor
|
🚀 Successfully created version bump PR: #813 |
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.
OPDATA-6745
Description
There is a memory leak in
Requester.If requests come in frequently enough that the requester queue is never empty, even if it stays at a small size, the recursive
processNextfunction will chainPromiseobjects forever. Only when the request queue is empty, does the promise stack unravel to release the memory.This happens in
por-address-list,the-network-firm,tiingoand to a lesser extentfinnhub-secondarybecause they have multiple endpoint making multiple requests. This means that even though one endpoint waits for all its requests to finish before sending a new batch, there is always a batch from another endpoint still in the queue to keep the promise chain from unraveling.This PR fixes the memory leak by refactoring the
Requester, in particular the queueing process.Instead of dropping requests in a queue and separately handling the queue, the code is more procedural with each "thread" taking care of its own request and a queue that only coordinates how requests wait on each other to satisfy the rate limiter.
Changes
turn-queue.ts. This coordinates the different "threads" waiting on the rate limited sequentially.TurnQueue.Requesterusing theTurnQueue.Testing
Tested locally with
the-network-firmwith all 24 feeds from RDD.We'll confirm that it fixes the memory leak when we test in staging after merging.