#Upgrading from v3 to v4 all of my tasks stuck in QUEUE status

1 messages · Page 1 of 1 (latest)

rigid citrus
#

Hello team
I was trying the migration guide from trigger v3 to v4 and after that all my tasks in dev enviroment has been stuck in the QUEUE status. Also when I'm running trigger locally I can't see the tasks any more in my console, I can have access to the dispatcted tasks only through dashboard

Can someone help me?

keen peakBOT
#

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";
#

[Deprecations]

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:

  1. Run npx trigger.dev@latest update to ensure all packages are on v4.
  2. Run npx trigger.dev@latest dev locally and check for any errors in the console output.
  3. 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.

spark cypress
#

hey, are you running the latest version of the sdk? If so, please share the link to some of these runs. thanks!

rigid citrus
#

hello, yes I'm runnign the latest skd version. these are some runs ids: run_kct1o9sie2zwvcm3p3fks, run_tpjmb46bgm8ppb2mw16bd

novel spindle
#

Experiencing the exact same thing

rigid citrus
#

@spark cypress any update here?

spark cypress
#

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

rigid citrus
#

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

novel spindle
#

Same here. We're still getting the same issue

spark cypress
#

@rigid citrus are you self hosting?

novel spindle
#

nope

rigid citrus
#

@spark cypress nope

#

any update @spark cypress

tough estuary
#

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)

tough estuary
#

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.

spark cypress
#

hey @tough estuary , thanks for the detailed bug report, it's been received and we will look at it today

#

@rigid citrus , please share a link to those runs, i can't find the run id in the database for some reason