Some tasks missing after migrating to v4

[crude berry]

We just migrated from v3 to v4 and more than half of our tasks are not deployed (72 to 30).

No errors, nothing. Except multiple task runs in "Pending version".

FYI, in our trigger.config.ts we use multiple directories (dirs) and also use ignorePatterns. These have no changed during migration.

[limpid mica]

Hi @crude berry. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

---

Based on the knowledge sources, there is no explicit documentation about tasks going missing after migrating from v3 to v4, nor about a reduction in the number of deployed tasks without errors. However, here are some points to consider based on the available information:

• The dirs and ignorePatterns options in trigger.config.ts control which directories and files are included or excluded from the build. If these have not changed, and you previously saw all tasks deployed, they should still work as before—unless v4 has changed how it interprets these patterns. The documentation does not mention any changes to the behavior of dirs or ignorePatterns between v3 and v4, but it does recommend specifying directories explicitly and notes that files with .test or .spec in the name are automatically excluded unless you override this with ignorePatterns The trigger.config.ts file.

• The migration guide does not mention any changes to how tasks are discovered or bundled, but it does note that the config file is bundled with your project and that imports in the config file can affect build times and cold start duration. It also mentions that anything defined in the build config is stripped out, and imports used inside build config are tree-shaken out The trigger.config.ts file.

• If tasks are showing as "Pending version," it may indicate that the deployment did not fully complete or that the new version was not promoted. The documentation describes how to use the --skip-promotion flag and how to promote a version manually, but does not mention tasks being stuck in "Pending version" Deployment > Versions.

• There is a troubleshooting section that suggests using a dry run (npx trigger.dev deploy --dry-run) to inspect what is being built and uploaded, and using debug logs (--log-level debug) to get more information about the deployment process. This may help you identify if tasks are being excluded during the build process Deployment > Troubleshooting.

Summary:
The knowledge sources do not explicitly mention a known issue with missing tasks after migrating to v4, nor changes to dirs or ignorePatterns that would explain this. I recommend running a dry run and checking the build output to see which tasks are being detected and included. If the issue persists, consider enabling debug logs or reaching out to the Trigger.dev team via their Discord for further assistance.

If you discover that certain files or directories are being excluded unexpectedly, double-check your dirs and ignorePatterns settings, and ensure that your task files do not match any exclusion patterns (including the default .test or .spec patterns) The trigger.config.ts file.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

@crude berry Kapa.ai is still learning and improving, please let me know how I did by reacting below.

[crude berry]

We're also running the sentryEsbuildPlugin

  build: {
    extensions: [
      esbuildPlugin(
        sentryEsbuildPlugin({
          org: 'wavo',
          project: 'api',
          // Find this auth token in settings -> developer settings -> auth tokens
          authToken: process.env.SENTRY_AUTH_TOKEN,
        }),
        { placement: 'last', target: 'deploy' }
      ),
    ],
  },

[tall locust]

@crude berry is there a pattern to which ones are missing? Is it a certain folder or pattern?

[sullen spade]

Hi Matt,
I'm working on this project with @crude berry and I just wanted to bring some precisions here.

In our trigger.config.ts, we have: init: async () => { someFunction() }

And in this function, we setup some listeners, whose actions can be to trigger other Trigger tasks
When I comment out the code in this listener that triggers another task (// someTask.trigger(...)), the task someTask is uploaded to Trigger.dev again!
It seems that all of the tasks that are triggered in this listener won't be uploaded to Trigger.

If I comment out the call that sets up the listener (someFunction) in init, all tasks are uploaded to Trigger again

What I don't get is that this code is not run in the init function, we're only setting up listeners that might trigger other tasks.

Hope this helps. I'm available should you need any info.

Cheers

[brazen shuttle]

I don't think anyone has ever tried to import tasks in the trigger config file before, so congrats on being the first!

Could you shed some light on what you're trying to achieve here? What kinds of listeners are these? Did you successfully use them in v3?

In the meantime, you could try to use the { tasks } export instead and only import task types. See this: https://trigger.dev/docs/triggering#tasks-trigger

[sullen spade]

Hi Nick,

Thanks for a quick answer!

We have an event-driven architecture, so most of the time a tasks finishes with the creation on an event. We listen to creations of such events to trigger the relevant workflows afterwards.

For example, we could have a task renewCustomerSubscription, at the end of which we would create an event of the type CustomerSubscriptionRenewed. Once an event of the type CustomerSubscriptionRenewed has been emitted, we want to trigger the task warnCustomerAboutRenewal.
This is what our listener does: it maps every event to the workflow supposed to be trigger once this event is emitted.

In v3, the listener worked just fine, and we have already tried updating the imports as per the migration recommendations. I'll try the types-only importing way!

[sullen spade]

Importing just the types seems to solve the problem.
Is this the only way? Can't we do myTask.trigger(...) like we used to?

[sullen spade]

We still have an issue actually. We have some functions that trigger multiple tasks (someTask1, someTask2, someTask3) that are called either by another task or directly by the backend. How are we supposed to handle these?

[brazen shuttle]

I think this is a special case due to importing tasks in the config file declaration. You might have more success with middleware: https://trigger.dev/docs/tasks/overview#middleware-and-locals-functions

Re triggering multiple tasks, that should be covered by the tasks export too, there's a number of methods that accept types: https://trigger.dev/docs/triggering#triggering-from-your-backend

I'd try the latter as a quick fix, in the longterm migrate to middleware. I don't think anyone has tried to use it in this way yet so please let us know how it goes!

[crude berry]

Hi Nick,

Like @sullen spade wrote, we have an event handler that can be executed on our app context or on the trigger context. The event handler is basically a big switch/case on the event type, which triggers either static methods, either tasks, some times both.

What should we use to trigger tasks when the call can be from either the app context or the trigger context ?

It worked flawlessly in v3, by triggering via taskABC.trigger(payload)