<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/v3/wait-for-request">https://trigger.dev/docs/v3/wait-for-request</a>

In Review

Wait For Request

Michał Kowalkowski

At the moment you can't delete a v3 project. You can rename them from "Project settings", but they can't be deleted.

Delete a v3 project

Linear

Inside your run function it would be useful to be able to pause execution until something external has happened.
We had a feature called "wait for event" in v2 that allowed you to do this. You could then send an event from your own code and the run would continue where it left off.
An example might be for an application process where the application needs to go through an approval step e.g. an AML check.
There would be a timeout of how long it would wait, with a default.

Continue after event ("wait for event")

I want to be clear what this feature is and isn’t.It would mean having worker machines in a datacenter in the EU. This would allow you to access APIs that are geo-IP restricted. It means the compute would happen in the EU.It does NOT mean that the data for those runs would reside in the EU. The operational and log data for all of <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> cloud is located in US-EAST-1. To have European data we would need to have multiple databases and log stores. This isn’t trivial – most companies that do this get you to select when you create your account between EU and US. If you do want this please create a separate feature request.

EU located workers

mattaitken

We currently support setting a <code>concurrencyLimit</code> on a task, or on a queue that you create. This can also be used with a <code>concurrencyKey</code> to have per-user queues: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/queue-concurrency">https://trigger.dev/docs/queue-concurrency</a>Sometimes instead of concurrency you want to limit using a rate. For example, 10/minute, 1/second.This is especially useful when using APIs that have rate limits.We should support this with a per-tenant key like we do for concurrency.

Rate Limiting on V3

An Anonymous User

You can only provide 100 items in <code>batchTrigger</code> and <code>batchTriggerAndWait</code> at the moment. if you want to batch more items than this you need to call it multiple times, creating more than one batch.
We should add a way to create larger batches. It would involve multiple API calls and we'd probably want to make that explicit. For example, you would create a batch, add items to it and then finalize it.

Support more than 100 items in `batchTrigger` at once

To access some databases, and other services, you need to provide them with an IP whitelist. 
For this to work well we need to have static IPs, potentially a per customer IP address.

Static IP addresses

In the dashboard you each task would have a URL for each of your environments.Then you can use this URL in 3rd party products. Any data in the body of the request to that URL would come through to the task as the payload.

Incoming webhook trigger

You can <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/open-source-self-hosting">fully self-host Trigger.dev</a>. This is a really good option in lots of situations if your experienced with setting up and managing infrastructure. Another option would be if we offered self-hosted workers. You would host them inside your own cloud account (or on-prem) and they would connect to the <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> cloud.

Self-hosted workers

Please reintroduce the events feature in V3, similar to what was available in V2. <ul><li>Trigger with an event name and payload</li><li>A task can subscribe to a named event with a filter (it will only create a run if the filter matches)</li><li>A single event can trigger many tasks if it matches many</li></ul>

Event triggers

This could do two things:
<ol>
<li>Sync environment variables from Vercel to Trigger.dev.</li>
<li>Create preview deployment on Trigger.dev for each preview deployment on Vercel.</li>
</ol>
We need to figure out the details of how preview deployments would work with API keys, environment variables and filtering.

Planned

Vercel integration

The ability to create additional environments that you name, e.g. “Sandbox”.They’d get assigned API keys, you could filter by them, etc.You could clone them from another environment, and delete them.

More environments

Easily get realtime data from your task runs to your frontend (or backend).This would include basic stuff:<ol><li>Run status</li><li>Run payload</li><li>Run output</li></ol>But also more advanced use cases:<ol><li>Being able to send structured (and typed) data from inside your run functions to your frontend.</li><li>Being able to stream data from inside your run function to your frontend.</li><li>Being able to send React Server Components from your run function to you frontend. Maybe. We're trying to figure out if this is possible.</li></ol>

In Progress

Realtime notifications

When you trigger a prod or staging run in the Trigger.dev cloud it takes 4 seconds on average for the machine to start up and your code to start executing. This same slowness happens when a run resumes, like after using <code>wait.for</code> if the delay is above a threshold when we shut the machine down.
They take this long because we're using Kubernetes for our cluster and a new pod takes a while to come up.
We're switching to using Firecracker for the cloud machines. Our target is to get the p95 for starts and resumes to under 500ms. The other benefit of Firecracker is that the built-in security model is much better.

Make runs start/resume faster (using Firecracker)

SOC2 compliance

There are two things that aren't great about deploying at the moment:<ol><li>You can end up having to add a lot packages to <code>dependencesToBundle</code>.</li><li>You need to match the versions between the SDK and the CLI.</li></ol>We are changing the way we bundle your code so it works without intervention in more situations. Mainly this means changing to use ESM – we are currently using CJS because of one of our dependencies.We are also going to change to a single package for the CLI and SDK. This means it will be impossible to have version mismatches between them.

Completed

Make deploying (bundling) much easier

Some libraries require binaries that are usually installed inside a Docker image. These are particularly useful in background jobs because you want to do things like audio/video processing or browser automation.
Note: 
<ul>
<li>You can use ffmpeg currently using the <code>ffmpeg-installer</code> package.</li>
<li>You can use Puppeteer by using puppeteer.connect with browserWSEndpoint. We recommend using it with BrightData.</li>
</ul>

Support for binaries

Currently you need to have a <code>tsconfig</code> file for our CLI to work and we run a typecheck before running your code.
Should we add support for vanilla JS?

JavaScript support

An optional property on a task (or passed in when triggering) that would fail the task if it exceeds that amount of duration. Should it be clock time from when it starts executing? Or compute time? (e.g. ignore waits)

Support a maximum duration of a run

You can add tags to a run when you <code>trigger()</code> them and/or inside the run function.This allows you to do advanced filtering in the dashboard and with the SDK.Full details here: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/changelog/run-tags">https://trigger.dev/changelog/run-tags</a>

Ability to add `tags` to a run

In the dashboard you should be able to edit the payload when you use the "Replay" button.
In the modal that pops up to confirm the replay we should show the payload. You could edit it if you wanted to before hitting "Replay".

Replay a run but be able to edit the payload (dashboard)

You can now attach schedules directly to your scheduled tasks. They sync when you run the dev or deploy commands.More info here: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/changelog/declarative-cron">https://trigger.dev/changelog/declarative-cron</a>And in the docs: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/v3/tasks-scheduled">https://trigger.dev/docs/v3/tasks-scheduled</a><pre><code>import { logger, schedules } from "@trigger.dev/sdk/v3";

export const checkMetrics = schedules.task({
 id: "check-metrics",
 //6am every day
 cron: "0 6 * * *",
 run: async (payload) =&gt; {
 const formattedTime = payload.timestamp.toLocaleString("en-US");
 logger.log(formattedTime);
 },
});</code></pre>

Static CRON attached to tasks

You can subscribe to notifications for when a run fails (all of its attempts). We currently support these three channels:<ul><li>Slack</li><li>Email</li><li>Webhook</li></ul>More info on how to use this here: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/troubleshooting-alerts">https://trigger.dev/docs/troubleshooting-alerts</a>

Alerts for run failures

Tags are a good improvement that will help us with filtering. However for our jobs, ideally we would need more than three. We want to track (on all jobs):<ul><li>The user `user_xxxx`</li><li>The organisation `org_xxx`</li><li>The entity that caused the job to run `device_xxx` (we run jobs to generate content for another entity in the database)</li></ul>And then additionally on some jobs:<ul><li>A reason (one of two values) `reason__partial` or `reason__full`</li></ul>It seems like it would be fair that you could support more than 3 tags on paid plans.

Support more than 3 tags

Ashley Williams

You can replay and cancel a run at the moment, but it only works if you've selected a task (blue item in the logs list).
We should add permanent buttons on the run page to replay and cancel the parent task.
We should also add "R" and "C" shortcuts to the Cancel and Replay buttons too.