Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Why is asyncFilter calling asyncBatch
See original GitHub issueThe call to asyncBatch seems to be there in order to provide concurrency, but batch does not provide any concurrency, it just delays the emission of results until more results are ready. This sucks! If you try to consume only a single result from asyncFilter with a concurrency higher than 1, it will never return! It’ll just sit there waiting for more items to put in its batch! Why would we sacrifice the correctness of the implementation for a perf optimization that we don’t even know we need, and clearly don’t know how to properly test?
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I have an even better approach that is almost ready to go which should actually be optimal and correct in every case.
I like this approach. you could leverage Promise.race, when the buffer is full.
In my use case I had a stream of ids and I need to retrieve data from a rest endpoint for every id. So calling these endpoints in parallel gave a great perf boost. (I am talking about asyncMap, but asyncFilter behaves the same)