#Upgrading from v3 to v4 all of my tasks stuck in QUEUE status
1 messages · Page 1 of 1 (latest)
Hi @rigid citrus. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
Tasks Stuck in QUEUE After v3 → v4 Migration
There are a few things to check based on the migration documentation:
1. Concurrency Limits / Queue Configuration Changes
In v4, queues must be defined ahead of time — you can no longer create them on-demand when triggering. If your old code was doing something like this:
// Old v3 way - no longer works in v4
await myTask.trigger({ foo: "bar" }, { queue: { name: "my-queue", concurrencyLimit: 10 } });
You need to define the queue explicitly first:
import { queue, task } from "@trigger.dev/sdk";
const myQueue = queue({
name: "my-queue",
concurrencyLimit: 10,
});
export const myTask = task({
id: "my-task",
queue: myQueue,
run: async (payload: any, { ctx }) => {},
});
await myTask.trigger({ foo: "bar" });
If queues aren't properly defined, runs may stay in QUEUED state. [Queue changes]
2. Check for Stuck/Stalled Runs Blocking the Queue
Runs in EXECUTING or DEQUEUED state count against concurrency limits. If any runs are stuck in those states, they may be blocking new runs from executing. Check your dashboard for any stalled runs. [Runtime issues]
3. Tasks Not Showing in Local Console
The fact that tasks are no longer visible in your local console when running trigger dev suggests the CLI may not be picking up your task files correctly. Make sure you're running the latest version of the CLI:
npx trigger.dev@latest dev
Also ensure your import paths have been updated from the deprecated path:
// Old (deprecated)
import { task } from "@trigger.dev/sdk/v3";
// New (correct)
import { task } from "@trigger.dev/sdk";
4. Dual-Engine Transition Period
During migration, there's a period where old v3 runs continue on the v3 engine while new v4 runs use the v4 engine. This can temporarily result in up to double the concurrently executing runs, which may cause queuing. This should normalize once v3 runs drain. [Migration guide]
Recommended next steps:
- Run
npx trigger.dev@latest updateto ensure all packages are on v4. - Run
npx trigger.dev@latest devlocally and check for any errors in the console output. - Review your queue definitions and concurrency limits in the dashboard.
If the issue persists, the Trigger.dev team recommends reaching out via Discord or their contact page for direct support.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
@rigid citrus Kapa.ai is still learning and improving, please let me know how I did by reacting below.
hey, are you running the latest version of the sdk? If so, please share the link to some of these runs. thanks!
hello, yes I'm runnign the latest skd version. these are some runs ids: run_kct1o9sie2zwvcm3p3fks, run_tpjmb46bgm8ppb2mw16bd
Experiencing the exact same thing
@spark cypress any update here?
A bug in our queue system meant some tenants (including you) couldn’t get runs dequeued from March 11th 9am UTC. Another tenant in your shard created ~120k queues and hit a limit (we only consider 1.2k per shard), so those queues stayed stuck and anything after them, including yours was never picked up.
What we’ve done: We’ve cleared the stuck queues in your shard and improved alerting so we catch this earlier. We’re also redesigning the fair-queue sharding so a single tenant can’t flood it like this again
ok let me give it a try and I will write an update
@spark cypress I'm facing the same issue, run ids: run_xm1gn8638vn7sr268r8qy run_s4c1g1pf5shhuxqq1dwrn, run_8cnwncm7vx72iaq6xhm91, run_sddt4u1rw1abnzg24wih3
If the issue still persist we need more days for the migration, we can't do it til EOM
Same here. We're still getting the same issue
@rigid citrus are you self hosting?
nope
I can't be certain this is the same problem, but since yesterday I've been having problems with runs stuck in waiting/queued.
I made a couple of tiny tweaks and then upgraded from 4.0.4 to 4.4.3, and since then I've not been able to get a batch to complete
I've got two runs stuck now, which I'll leave stuck in case someone can debug them: run_cmmvqivgug4tu0uohowzeyvua / run_cmmvqsgplg4rh0hn75u7rgbxp
(I'm also not self-hosting)
Performance appears to have degraded even further since this morning - I've emailed in a detailed bug report.
We're completely stuck so hopefully this is addressed soon.