The shift/always was obviously a brainfart. Fixing ...

Alright, seems to be working! I've added an example below.

Added support for invalidation. This might also be a sensible addition to fetchp.

funnel is not a semantic name. It's ordering operations. So maybe "orderedFetch" or "fifoFetch".

It's not strictly ordered, as a pool size > 1 can cause later requests to finish earlier than reqs that were pooled earlier. But it's your notebook, so pick whatever name you consider appropriate.

What does the pool achieve? Browsers have a concurrent limit already. If you want to calls to be fast and parallel, then don't use the funnel. I do not see a use case for pool =2 and it complicates the implementation and the message. If you want performance use fetchp, if you want ordering use fifofetch. There is no middle ground where funnel(pool = 2) makes sense over fetchp IMHO.

also the name should be fifoFetchp I expect. You may not always need the CORS, but you might want ordering, so that would be fifoFetch

I added the pool so that concurrency can be adjusted. E.g. if your CORS proxy allows up to three concurrent requests, then the pool size can be adjusted accordingly.

Browsers already have a concurrency safety limit and the backend is elastic anyway (also supports HTTP/2). Thus, the context needs to be very specific for the pool parameters to be useful. Thus, in my opinion, the pool feature does not justify the added complexity and should be removed. Also it blurs what the point of the funnel is anyway, as it breaks the one interesting property of ordering., making explination difficult.

Perhaps it's helpful to understand from which place this suggestion came: When I used fetchp() like I do below with Promise.all(), all requests would fire immediately, and would almost immediately fail due to the rate limit of the endpoint. I had to rewrite the fetching to an async/await for-of loop to force requests to be made one after the other. The funnel() wrapper takes away this overhead. But I didn't mean to put you on the spot with this suggestion. If you have no use for it, please feel free to close it. I can still reuse the funnel code in my API bridge notebook, so it hasn't been for naught. :)

(By the way, another name suggestion which might be more approriate than funnel(): throttle())

The issue with bursts being rejected has been solved by retrying on the 429 status code with exponential backoff. This is better than rate limiting clientside as its reactive to server capacity rather than jsut staying under some safe limit (which has to be a little conservative and therefore ineffecient). See https://en.wikipedia.org/wiki/Exponential_backoff The retry on 429 will automatically discover the right rate naturally, so we can change the serverside scaling characteristics and your code will take advantage of it without any retuning on your part. If you rebase onto the updated fetchp you will not have the same problem, however, it will end up reordering requests so then your fifo dynamic might be helpful still. But the tuning the concurrency parameter won't be necessary for your issue anymore.

I like examples but I package them as test cases. add suite.test("fifoFetch guarantees order ", () => .. expect(...))

I only added them in here, didn't intend for them to be merged.

yeah its ok I can do that anyway post merge