p-queue

Summary Adds a / accessor on , mirroring the existing accessor, so the rate limit can be adjusted after the queue has been created. Closes #177, which asks for exactly this ("The only thing required for this would be to control property of at runtime"). Changes is no longer ; added / with the same validation the constructor already does (must be a number >= 1, and must stay finite when is enabled). (an internal flag derived from /) is now recomputed via a small helper whenever changes, so it doesn't go stale. Setting calls the existing , so raising the cap immediately lets already-queued tasks start rather than waiting for the next interval tick (same behavior as the existing setter). README: documented that can be changed at runtime, and added the entry to the properties list (same pattern as ). Testing Added (mirrors the existing test). Added (mirrors the constructor's equivalent guard). Added , which proves the behavior end-to-end: with , only 1 of 4 queued tasks starts; raising to immediately starts 2 more without waiting for an interval tick. Verified RED/GREEN: reverting just makes the three new tests fail ( is currently read-only), confirming they exercise the reported gap; with the fix applied, passes all 209 tests. and both pass clean with no errors. currently fails on this checkout with "was not found by the project service" parsing errors on and everything under / — verified this is pre-existing and unrelated to this diff (same errors occur on a clean checkout of with no changes applied), likely an environment/path quirk in this sandbox rather than a real lint issue. Notes itself is intentionally left read-only in this PR to keep the change small — it drives timer/window scheduling (/) which needs more careful handling to change safely mid-window. Happy to follow up separately if that's wanted too.

Version:* 9.3.2 Behaviour When and tasks are spread across a window (first slot consumed early, last slot consumed later), tasks added after* the interval window expires are incorrectly held back — even though they belong to a fresh window. Reproduction Output: Root cause The fix for #182 introduced a guard inside that, when the interval timer is absent and has already passed, checks whether at least ms have elapsed since the most-recently-dequeued task: `` the last dequeued slot can be significantly later than the window's start, so overshoots the true window boundary. In the repro above: Window started at t≈0, so it expires at t=1000. Last task was dequeued at t≈600, so . Task C arrives at t=1100 (after true window expiry) but , so a 500 ms timeout is created and is never reset. Task C is blocked until t≈1600 even though it is in window [1000, 2000) and both slots are free. Expected behaviour A task added after has passed should experience no additional delay regardless of when within the previous window the last slot was consumed. The window boundary () already captures this correctly; the check should not extend it.

Bug The constructor validates the global option and throws a clear for non-positive values. But accepts per-task without any equivalent check. This leads to two silent failure modes: Case 1 — silently disables the global timeout The guard inside is: \\\ is falsy, so bypasses the wrapping entirely. If a queue was constructed with , passing to a specific task silently drops the timeout for that task. There's no error and no documentation of this escape hatch. Case 2 — produces a cryptic internal error validates its argument and throws synchronously when it's not strictly positive. That TypeError propagates out of as an unhandled rejection — but the message names internals, not the call-site, making it hard to trace. Expected Both cases should throw a clear at the call-site, consistent with the constructor: \\timeout0\ Suggested fix After merging options in , add: \\Expected \ to be a positive finite number, got \\ And change the guard from to . Repro \\\