AsyncQueuer: concurrency > 1 not honoured for items added while another is executing (regression in 0.22.0)
Maintainers usually reply within 2 days
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 66/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- node.js, typescript
- Domain
- backend
Research direction
Start with the AsyncQueuer addItem path and its private #tick logic, especially the pendingTick guard described in the issue. Run the linked gist with @tanstack/pacer 0.22.0 and 0.21.1 to compare behavior. Done means adding items while an execution is pending fills every available concurrency slot without bypassing wait behavior.
Written by the indexing model from the issue text.
Description
TanStack Pacer version
@tanstack/pacer v0.22.0 (via @tanstack/react-pacer v0.23.0). Last working version: @tanstack/pacer v0.21.1 (@tanstack/react-pacer v0.22.1).
Framework/Library version
Reproduced with the core package on Node.js v25.9.0 (no framework). Originally seen through useAsyncQueuer with React v19.3.0.
Describe the bug and the steps to reproduce it
Since @tanstack/pacer 0.22.0, an AsyncQueuer with concurrency: 2 runs items one at a time when they are added one after another, for example one addItem() per user click. The second item waits for the first to finish even though a concurrency slot is free. On 0.21.1 both start immediately.
Steps:
- Create an
AsyncQueuerwith{ concurrency: 2, wait: 0 }and a task that stays pending (a long download, say). - Call
addItem("a"), thenaddItem("b"). - Check how many tasks have started.
Expected: 2 started, 2 active, 0 pending (what 0.21.1 does).
Actual on 0.22.0: 1 started, 1 active, 1 pending.
import { AsyncQueuer } from "@tanstack/pacer";
let started = 0;
const queuer = new AsyncQueuer(
async () => {
started++;
await new Promise(() => {}); // a long-running task
},
{ concurrency: 2, wait: 0 },
);
queuer.addItem("a");
queuer.addItem("b");
await new Promise((r) => setTimeout(r, 50));
const { activeItems, items } = queuer.store.state;
console.log({ started, active: activeItems.length, pending: items.length });
@tanstack/pacer |
output |
|---|---|
| 0.21.1 | started=2 active=2 pending=0 |
| 0.22.0 | started=1 active=1 pending=1 |
Likely cause: #246 (the fix for #188) keeps pendingTick: true while executions are in flight (#tick: "pendingTick must stay true while executions or wait timers are pending"), and addItem only calls #tick() when !pendingTick. So an item added during an execution isn't picked up until that execution settles and re-ticks, even though a slot is free. main still has the same guard. The #188 intent (don't bypass wait) seems to need the guard only while a wait timer is armed, not while an execution runs with free slots.
(Investigated with AI assistance. The repro and the version comparison above were run and checked by hand.)
Your Minimal, Reproducible Example - (Sandbox Highly Recommended)
https://gist.github.com/ilyaauditoo/710aab918995470c11960aa9e33ff0f0 — npm install && npm start (pins @tanstack/[email protected]; change it to 0.21.1 to see the expected behaviour).
Screenshots or Videos (Optional)
No response
Do you intend to try to help solve this bug with your own PR?
Yes, I think I know how to fix it and will discuss it in the comments of this issue
Terms & Code of Conduct
- I agree to follow this project's Code of Conduct
- I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.
- Dominant language
- TypeScript
- Stars
- 776
- Forks
- 67
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 11
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from TanStack/pacer
-
replace deprecated Vitest spy assertion aliasesPossibly taken @2yunseong claimed this 21 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 2 days
-
Queued AsyncDebounce execution is silently dropped if it is executed after an in-flight run completesPossibly taken @SimenB claimed this 13 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 75/100
Maintainers usually reply within 2 days
-
Async utilities count swallowed retryer failures as successes and call onSuccess(undefined)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 2 days
-
debouncer.getAbortSignal() returns null due to maybeExecuteCount increment mismatchPossibly taken @SimenB claimed this 13 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
Maintainers usually reply within 2 days
-
with devtools added getting export setStyleProperty was not found in module errorPossibly taken @restareaByWeezy claimed this 211 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 48/100
TanStack/pacer#131 · 3 comments · 4 reactions ·
Maintainers usually reply within 2 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
platformatic/mcp#208 ·
Maintainers usually reply within 1 day
-
🐛 bug
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
margelo/react-native-vision-camera#4211 ·
Maintainers usually reply within 4 days