p-queue

can resolve much later than it should. It only re-checks its condition on task completions, so when the queue drains below the limit without a task finishing, the returned promise stays pending until the next unrelated completion. Raising at runtime on a running queue shows the same shape: several tasks are dequeued synchronously and falls below the limit, but doesn't settle until a task later completes. The everyday completion-driven case (a running queue whose size falls as tasks finish) resolves promptly, so the gap is specific to non-completion drains: + , a runtime increase, and interval ticks under rate limiting. Mechanism: waits on the event, and is emitted on task completion (), on a queued-task abort, and in . The bulk-dequeue in emits / / but not , so any size decrease that isn't a completion never wakes the waiter. The queued-abort handler already emits right after it removes an item from the queue — so the intended contract looks like "emit whenever the waiting set shrinks," and the dequeue path just doesn't follow it. Emitting after a successful in (guarding against a double-emit on the completion path, which also calls it) would line the two up. Happy to send a PR if that direction sounds right.

Summary clarify the autoStart sentence in the README Related issue N/A (trivial docs wording fix) Guideline alignment CONTRIBUTING: none found in the repo root or .github on main PR template: none found in the repo root or .github on main Validation Not run (docs-only change)

Feature request The getter provides useful debug information about currently executing tasks (id, priority, startTime, timeout). However, it doesn't expose how much time is remaining before a task times out. Proposed solution Add a computed field to each running task entry that shows the remaining timeout in milliseconds: Use case This would be useful for monitoring and debugging long-running tasks, allowing users to see at a glance which tasks are about to time out.