#Message Max Size 262144
1 messages · Page 1 of 1 (latest)
Hi @subtle wren,
Unfortunately this is a limitation when using client.sendEvent which is imposed by AWS SQS which we're using so we can accept millions on events and be more resilient to downtime. I've made a note to see if we can look at an alternative that has a higher limit.
However I think there might be a solution for you. We don't current use SQS when use the invokeTrigger instead of the eventTrigger.
https://trigger.dev/docs/documentation/concepts/triggers/invoke#payload-schema
The only downside to the invoke trigger is that you have to specifically invoke a Job. You can't send an event and have multiple jobs run based on the event name.
Would this work for you?
Matt, thank you! That's perfect for me. I would normally use invokeTrigger for this use case anyway but recently I've been using eventTriggers because whenever I instantiate an invokeTrigger, the typings cause my IDE to freeze up due to "infinitely deep typings" - this isn't an issue for eventTrigger.
My IDE is the latest version of VS code, if thats relevant
Uh this is such an annoying issue. This is caused by a mismatch between the Zod you're using in your project and the Zod we have inside our SDK… it's an issue for all packages that use Zod internally, like tRPC as well. There's an issue here: https://github.com/triggerdotdev/trigger.dev/issues/727
Currently the only fix is for you to use the same version of Zod as us. We're using Zod 3.22.3 at the moment.
We might have figured out a permanent fix for this where we use an arrow function and pass you our Zod to use. But it's not ready yet.
Thanks Matt! Appreciate it, you and your team are doing god's work 🙏
I can't imagine my life without trigger now that I've started using it haha
Do you have plans to work on a feature to enable users to set artificial limit on concurrent job runs, within each job? I'd like to schedule this job to only run serially (i.e., only one instance of the job should be running at a time, since multiple instances would make conflicting edits to the given resource). I know that there's an account-level limit on concurrent runs but it'd be useful to have some kind of a serial execution property on a per-job basis.
You can already do this 
There are two ways:
- A limit on a single Job.
- A shared limit across multiple Jobs.
- A single Job limit:
client.defineJob({
id: "something",
name: "Something",
version: "0.1.0",
trigger: invokeTrigger(),
//one at a time
concurrencyLimit: 1,
run: async (payload, io, ctx) => {
},
});
- A shared Job limit:
const concurrencyLimit = client.defineConcurrencyLimit({
id: `test-shared`,
limit: 5, // Limit all jobs in this group to 5 concurrent executions
});
client.defineJob({
id: `test-job-1`,
name: `Test Job 1`,
version: "1.0.0",
trigger: eventTrigger({
name: "test",
}),
concurrencyLimit,
});
client.defineJob({
id: `test-job-2`,
name: `Test Job 2`,
version: "1.0.0",
trigger: eventTrigger({
name: "test",
}),
concurrencyLimit,
});
Docs for single: https://trigger.dev/docs/sdk/triggerclient/instancemethods/define-job
Docs for shared: https://trigger.dev/docs/sdk/triggerclient/instancemethods/concurrency-limit
Wow that's amazing, thanks Matt
Also something that might be helpful to users is replacing "dev": "next dev" in package.json with "dev": "next dev & npx @trigger.dev/cli dev" which runs trigger concurrently w/ ur own dev server without having to open another terminal instance to launch it, not sure if this is in the docs already to share w/ everyone but it's a massive convenience over hundreds of debugging sessions