p-throttle

Strict weighted throttling checks capacity at a new call's requested execution time, but can overlook capacity already reserved for later calls. For and : A weight-4 call runs at time 0. A weight-5 call is reserved for time 100. A weight-1 call arrives at time 50 and currently runs immediately. The calls at times 50 and 100 then have a combined weight of 6 in a single interval, exceeding the limit. Check each affected window, including those ending at future reservations, before scheduling a call. Advance past a blocking reservation until the new call fits. Zero-weight calls remain immediate, and smaller calls can still run earlier when doing so respects existing reservations. Validation: passes (XO, 90 runtime tests, and tsd). The added deterministic clock/timer regression fails before the fix and checks the weight limit at every execution. An additional local probe checked 200 seeded scenarios totaling 8,000 calls without a sliding-window violation. AI assistance: OpenAI Codex assisted with diagnosis, implementation, and testing.

I need this feature, I would be happy to submit a PR if you give me a quick tip on how you think it should be implemented. Same as the lodash options. https://lodash.com/docs/4.17.11#throttle

Continuing #2, I am concerned with the simple scenario where the rate at which executions are being made exceeds the rate at which they are resolved due to the throttling config. This time, the concern is not around memory exhaustion, but around the ever-growing delay in executing the next call being made. Using the function is a way to deal with this situation, with two drawbacks as I see them: it is hard to employ this 'flushing' with precision. For example, periodically checking the throttler to see how many pending executions are there, 'flushing' only several of them, choosing whether to 'flush' by FIFO or LIFO, etc. when pending executions are aborted, they reject with an . I'd love to have an option to have aborted executions resolve with a value that depends on the execution arguments. As a solution, I'm basically thinking of adding a way to peek into the throttledFn object, and extending the function with the following argument: Would appreciate feedback on relevance, direction, and anything else.