2.0.1 - Fixes and improvements

This release fixes various issues with run executions, including a pretty gnarly memory bloat issue when resuming a run that had a decent number of completed tasks (e.g. anything over a few). This has been released to cloud.trigger.dev but if you are self-hosting I recommend upgrading to this version ASAP.

Other notable fixes:

• Run executions no longer are bound to a queue, which will allow more parallel runs in a single job (instead of 1). @ericallam
• Serverless function timeouts (504) errors are now handled better, and no longer are retried using the graphile worker failure/retry mechanism (causing massive delays).
• Fixed the job_key design of the performRunExecutionV2 task, which will ensure resumed runs are executed
• Added a mechanism to measure the amount of execution time a given run has accrued, and added a maximum execution duration on the org to be able to limit total execution time for a single run. The default is 15 minutes and is stored in the Organization.maximumExecutionTimePerRunInMs column
• Improved the dashboard performance when viewing a run with large task outputs. The perf issue was on account of syntax highlighting so any task with an output of greater than 1k lines will forego syntax highlighting.
• #394 : Reduced graphile worker load by decreasing max attempt counts on tasks that hit development endpoints (thanks @Chigala!)

@trigger.dev/[email protected]

Patch Changes

Added additional triggers for PaymentIntent and Payout events (a1078249)

@trigger.dev/[email protected]

Patch Changes

• Only use cached tasks if they are completed, otherwise retrying tasks will be considered successful (916a3536)
• Updated dependencies:
  • @trigger.dev/[email protected]

@trigger.dev/[email protected]

Patch Changes

• Fixes #391, now handling jobs when using new Job instead of client.defineJob (3028b6ad)

@trigger.dev/[email protected]

Patch Changes

• provided a fix to the CLI dev command tunnel not working if you are already running ngrok (#407)
• fix: init will no longer fail when outside of a git repo (3028b6ad)
• feat: Checks for outdated packages when running the dev command with instructions on how to update (#412)

Platform v2.0.0 and `@trigger.dev/*` at v2.0.11

Trigger.dev v2.0.0

We've dropped the beta label on our v2.0.0 release of the Trigger.dev service, and moving forward we'll be updating the version number like good semantic version citizens.

The following changes have been made in the last few weeks:

Increased performance

We've redesigned the way we queue and execute job runs in order to increase the speed of job execution.

• Fixed the cached task miss issue in the @trigger.dev/sdk which should speed up resumed runs by A LOT
• Allow setting graphile worker concurrency settings through env vars WORKER_CONCURRENCY and EXECUTION_WORKER_CONCURRENCY
• Allow settings prisma pool settings through env vars DATABASE_CONNECTION_LIMIT and DATABASE_POOL_TIMEOUT
• You can now selectively enable/disable the workers through WORKER_ENABLED=false and EXECUTION_WORKER_ENABLED=false. This means the image can be deployed as 2 or 3 separate services:
  • A WebApp service that serves the API and the Dashboard
  • A Worker service that runs tasks that have been added the standard worker
  • An Execution Worker service that only runs "run execution" tasks
• Deprecated the JobOptions.queue options as we are no longer using that to control job concurrency. We'll add proper queue support in the future.

Fixed runs with large task outputs

We had an issue where runs that included tasks that had large task outputs could not be resumed after a delay.
This was because we send completed task outputs in the request body when we resume a run, and some platforms have a limit on the size of the request body.
We now cap the size of the task outputs we send in the request body to 3.5MB.

Disable and delete jobs

You can now disable jobs in your code by setting the enabled option to false:

client.defineJob({
  id: "example-job",
  name: "Example Job",
  version: "0.1.0",
  trigger: eventTrigger({ name: "example.event" }),
  enabled: false,
  run: async (payload, io, ctx) => {
    // your job code here
  },
});

Which will show the job as disabled in the dashboard:

Once you've disabled your job, you can delete it from the dashboard:

For more detailed information, checkout our documentation on managing jobs.

Cancel delayed events

When sending events, you can delay the delivery by setting either the deliverAt or deliverAfter option:

await client.sendEvent(
  {
    id: "event-1",
    name: "example.event",
    payload: { hello: "world" },
  },
  {
    deliverAfter: 1000 * 60 * 60 * 24, // 1 day
  }
);

You can now easily cancel delayed events to prevent subsequent job runs with the new cancelEvent method:

await client.cancelEvent("event-1");

This functionality requires @trigger.dev/[email protected] or later.

@trigger.dev/openai v2.0.11

We've updated our OpenAI package to use the new and improved v4 of the OpenAI SDK.

All of our existing tasks should work as before, but now when you use the .native property you'll get back and nice and shiny v4 SDK:

import { OpenAI } from "@trigger.dev/openai";

const openai = new OpenAI({
  id: "openai",
  apiKey: process.env["OPENAI_API_KEY"]!,
});

// Before: v3 SDK
openai.native.createCompletion({...});

// Now: v4 SDK
openai.native.completions.create({...});

We've also added some new tasks for enabling fine tuning jobs:

• createFineTuningJob - Create a fine-tuning job for a fine-tuning model
• retrieveFineTuningJob - Retrieve a fine-tuning job for a fine-tuning model
• listFineTuningJobs - List fine-tuning jobs for a fine-tuning model
• cancelFineTuningJob - Cancel a fine-tuning job for a fine-tuning model
• listFineTuningJobEvents - List fine-tuning job events for a fine-tuning model

@trigger.dev/cli v2.0.11

Our CLI has been updated with some fixes and improvements:

• 3ce5397: Added the send-event command
• 3897e6e: Make it more clear which API key the init command expects
• dd10717: Added --hostname option to the cli dev command
• 8cf8544: Bugfix: @trigger.dev/cli init now correctly identifies the App Dir when using JS (thx @Chigala ✨)
• 4e78da3: fix: Add an update sub-command the @trigger.dev/cli that updates all @trigger.dev/* packages (thx @hugomn ✨)
• 135cb49: fixed the cli init log message to show the correct path to the app route created (thx @Chigala ✨)

@trigger.dev/react v2.0.11

• a907e2a: chore: updated the type in the eventId argument (thx @Chigala ✨)

New package: @trigger.dev/astro ✨

Thanks to Liran Tal, we now have a native package to use Trigger.dev with Astro.

This is just the beginning and you can keep track of our progress on bringing Trigger.dev to Astro here

How to update

To update your existing projects to the latest version of the SDK, run the following command:

npx @trigger.dev/cli update

If you are self-hosting the Trigger.dev service, you'll need to update to the latest image:

docker pull triggerdotdev/trigger.dev:v2.0.0
# or
docker pull triggerdotdev/trigger.dev:latest@sha256:00d9d9646c3781c04b84b4a7fe2c3b9ffa79e22559ca70ffa1ca1e9ce570a799

If you are using the Trigger.dev Cloud, you'll automatically get the latest version of the service.

Upcoming changes

We're working on some exciting new features for upcoming releases:

Matt is working on our @trigger.dev/airtable integration, which will allow you to interact with Airtable from your jobs and trigger jobs on changes that occur in your Airtable bases. This one is taking a bit longer than expected on account of some interesting challenges and limitations in the Airtable Webhook implementation, but we're getting close.

Dan is working on a new Job Showcase repo and page on our public site to show off some example use-cases for Trigger.dev. We're hoping this will help people get started with Trigger.dev and give some ideas on how to use it in your own projects.

James is working on more dashboard improvements, which he'll be sharing on our Twitter/X soon.

Eric is working on a feature called Background Tasks, which will allow you to create specific tasks that can execute for up to 1 hour without pause. This will be useful for doing tasks that take longer than a serverless function timeout, like training ML models, or doing large data processing tasks.

As always, if you have any questions or feedback, please reach out to us on Twitter/X or Discord.