Releases: triggerdotdev/trigger.dev
[email protected]
Patch Changes
- 2b5771f: Remove duplicate bin definition, fixes issue #1311
- de135e4: Configurable deployed heartbeat interval via HEARTBEAT_INTERVAL_MS env var
- @trigger.dev/[email protected]
- @trigger.dev/[email protected]
@trigger.dev/[email protected]
Patch Changes
- @trigger.dev/[email protected]
@trigger.dev/[email protected]
@trigger.dev/[email protected]
@trigger.dev/[email protected]
Patch Changes
- @trigger.dev/[email protected]
2.1.0 – runTask changes and creating integration improvements
runTask changes (@trigger.dev/sdk 2.1.0+)
The most important change to be aware of is that we've moved the options param to the third param, and made it optional. When you upgrade your package, you will need to change the order (or if you want you can remove the options).
//old package (@trigger.dev/sdk v2.0.14)
const response = await io.runTask(
"my-task",
//this param is required, name is required, and it's before the callback
{ name: "My Task" },
async () => {
return await longRunningCode(payload.userId);
},
);
//new package (@trigger.dev/sdk v2.1.0)
const response = await io.runTask(
"my-task",
async () => {
return await longRunningCode(payload.userId);
},
//options are third, and they're not required. name isn't required, if you do pass options.
{ name: "My Task" }
);This change was made because it was sometimes annoying having to come up with a Task name, when there wasn't a good one. It also moves the most important param, the actual code you want to run, earlier.
New docker image: v2.1.0
If you're self-hosting you'll need to update to the latest image, before you update your packages to the latest. There are new API endpoints that the new packages use, as well as database migrations.
Integration improvements
Less rigid structure and generic support
Previously integrations had quite a rigid structure. Tasks could only live at the top-level. This also meant we couldn't do nice generic type support.
It meant we had slightly awkward names for some of the function calls as well.
//old package (@trigger.dev/openai v2.0.14)
const models = await io.openai.listModels("list-models");
//new package (@trigger.dev/openai v2.1.0)
//this still works
const models = await io.openai.listModels("list-models");
//this is new, and closely matches the official SDK structure
const models = await io.openai.models.list("list-models");We've made sure that the new integration packages are all backwards compatible. You won't need to update your code to use the more structured Tasks.
integration.runTask
All the integrations now have a runTask function that allows you to more easily use a native SDK function we don't support:
const price = await io.stripe.runTask(
"create-price",
async (client, task) => {
//client is the authenticated Stripe SDK
return client.prices.create(
{
unit_amount: 2000,
currency: "usd",
product_data: {
name: "T-shirt",
},
},
{
idempotencyKey: task.idempotencyKey,
}
);
},
//this is optional, it will appear on the Run page
{ name: "Create Price" }
);Creating integrations
It's now easier to make them, as we've dropped the concept of AuthenticatedTasks. It's more intuitive and like regular code you're used to writing. The guide in the docs on creating integrations needs updating still, but will be done soon including how to add webhooks (currently missing).
Airtable integration (but no webhooks… yet)
The integration changes were required to give a great experience with Airtable. You can set the types of your Table and then use the SDK with nice types.
const airtable = new Airtable({
id: "airtable-oauth",
});
//The types for my table
type Status = "Live" | "Complete" | "In progress" | "Planning" | "In reviews";
type LaunchGoalsAndOkRs = {
"Launch goals"?: string;
DRI?: Collaborator;
Team?: string;
Status?: "On track" | "In progress" | "At risk";
"Key results"?: Array<string>;
"Features (from 💻 Features table)"?: Array<string>;
"Status (from 💻 Features)": Array<Status>;
};
client.defineJob({
id: "airtable-example-1",
name: "Airtable Example 1: getRecords",
version: "0.1.0",
trigger: eventTrigger({
name: "airtable.example",
schema: z.object({
baseId: z.string(),
tableName: z.string(),
}),
}),
integrations: {
airtable,
},
run: async (payload, io, ctx) => {
//set the type on the table
const table = io.airtable.base(payload.baseId).table<LaunchGoalsAndOkRs>(payload.tableName);
//now everything that uses table has nice types
const records = await table.getRecords("multiple records", { fields: ["Status"] });
await io.logger.log(records[0].fields.Status ?? "no status");
const aRecord = await table.getRecord("single", records[0].id);
const newRecords = await table.createRecords("create records", [
{
fields: { "Launch goals": "Created from Trigger.dev", Status: "In progress" },
},
]);
const updatedRecords = await table.updateRecords(
"update records",
newRecords.map((record) => ({
id: record.id,
fields: { Status: "At risk" },
}))
);
await io.wait("5 secs", 5);
const deletedRecords = await table.deleteRecords(
"delete records",
updatedRecords.map((record) => record.id)
);
},
});That Job:
- gets all the records (rows)
- gets a single record
- create a new record
- updates the record that was just created
- waits 5 seconds
- deletes the record that was created/updated
Unfortunately Airtable webhooks aren't quite ready yet. Airtable send such frequent webhooks, like when a user is typing in a cell, we need to batch the updates together so we're triggering tons of runs. They're coming soon though.
Package updates
All of the packages have been updated to 2.1.0.
- @trigger.dev/airtable
- @trigger.dev/sdk
- @trigger.dev/github
- @trigger.dev/openai
- @trigger.dev/plain
- @trigger.dev/resend
- @trigger.dev/sendgrid
- @trigger.dev/slack
- @trigger.dev/stripe
- @trigger.dev/supabase
- @trigger.dev/typeform
- @trigger.dev/astro
- @trigger.dev/cli
- @trigger.dev/core
- @trigger.dev/eslint-plugin
- @trigger.dev/express
- @trigger.dev/nextjs
- @trigger.dev/react
Upgrading all your packages with the CLI
To upgrade to the latest packages, run npx @trigger.dev/cli@latest update
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!)
Contributors
Assets 2
@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]