Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork933
Comparing changes
Open a pull request
base repository:triggerdotdev/trigger.dev
Uh oh!
There was an error while loading.Please reload this page.
base:@trigger.dev/sdk@4.3.0
head repository:triggerdotdev/trigger.dev
Uh oh!
There was an error while loading.Please reload this page.
compare:main
- 9commits
- 127files changed
- 5contributors
Commits on Dec 16, 2025
feat(engine): Batch trigger reloaded (#2779)
New batch trigger system with larger payloads, streaming ingestion,larger batch sizes, and a fair processing system.This PR introduces a new `FairQueue` abstraction inspired by our own`RunQueue` that enables multi-tenant fair queueing with concurrencylimits. The new `BatchQueue` is built on top of the `FairQueue`, andhandles processing Batch triggers in a fair manner with per-environmentconcurrency limits defined per-org. Additionally, there is a globalconcurrency limit to prevent the BatchQueue system from creating toomany runs too quickly, which can cause downstream issues.For this new BatchQueue system we have a completely new batch triggercreation and ingestion system. Previously this was a single endpointwith a single JSON body that defined details about the batch as well asall the items in the batch.We're introducing a two-phase batch trigger ingestion system. In thefirst phase, the BatchTaskRun record is created (and possibly ratelimited). The second phase is another endpoint that accepts an NDJSONbody with each line being a single item/run with payload and options.At ingestion time all items are added to a queue, in order, and thenprocessed by the BatchQueue system.## New batch trigger rate limitsThis PR implements a new batch trigger specific rate limit, configuredon the `Organization.batchRateLimitConfig` column, and defaults usingthese environment variables:- `BATCH_RATE_LIMIT_REFILL_RATE` defaults to 10- `BATCH_RATE_LIMIT_REFILL_INTERVAL` the duration interval, defaults to`"10s"`- `BATCH_RATE_LIMIT_MAX` defaults to 1200This rate limiter is scoped to the environment ID and controls how manyruns can be submitted via batch triggers per interval. The SDK handlesthe retrying side.## Batch queue concurrency limitsThe new column `Organization.batchQueueConcurrencyConfig` now defines anorg specific `processingConcurrency` value, with a backup of the env var`BATCH_CONCURRENCY_LIMIT_DEFAULT` which defaults to 10. This controlshow many batch queue items are processed concurrently per environment.There is also a global rate limit for the batch queue set via the`BATCH_QUEUE_GLOBAL_RATE_LIMIT` which defaults to being disabled. Ifset, the entire batch queue system won't process more than`BATCH_QUEUE_GLOBAL_RATE_LIMIT` items per second. This allowscontrolling the maximum number of runs created per second via batchtriggers.## Batch trigger settings- `STREAMING_BATCH_MAX_ITEMS` controls the maximum number of items in asingle batch- `STREAMING_BATCH_ITEM_MAXIMUM_SIZE` controls the maximum size of eachitem in a batch- `BATCH_CONCURRENCY_DEFAULT_CONCURRENCY` controls the defaultenvironment concurrency- `BATCH_QUEUE_DRR_QUANTUM` how many credits each environment gets eachround for the DRR scheduler- `BATCH_QUEUE_MAX_DEFICIT` the maximum deficit for the DRR scheduler- `BATCH_QUEUE_CONSUMER_COUNT` how many queue consumers to run- `BATCH_QUEUE_CONSUMER_INTERVAL_MS` how frequently they poll for itemsin the queue### Configuration Recommendations by Use Case**High-throughput priority (fairness acceptable at 0.98+):**```envBATCH_QUEUE_DRR_QUANTUM=25BATCH_QUEUE_MAX_DEFICIT=100BATCH_QUEUE_CONSUMER_COUNT=10BATCH_QUEUE_CONSUMER_INTERVAL_MS=50BATCH_CONCURRENCY_DEFAULT_CONCURRENCY=25```**Strict fairness priority (throughput can be lower):**```envBATCH_QUEUE_DRR_QUANTUM=5BATCH_QUEUE_MAX_DEFICIT=25BATCH_QUEUE_CONSUMER_COUNT=3BATCH_QUEUE_CONSUMER_INTERVAL_MS=100BATCH_CONCURRENCY_DEFAULT_CONCURRENCY=5```
chore(ci): add manual trigger to the image publishing workflow (#2790)
Useful to retry failures manually.
Commits on Dec 18, 2025
feat(engine): run debounce system (#2794)
Adds support for **debounced task runs** - when triggering a task with adebounce key, subsequent triggers with the same key will reschedule theexisting delayed run instead of creating new runs. This continues untilno new triggers occur within the delay window.## Usage```typescriptawait myTask.trigger({ userId: "123" }, { debounce: { key: "user-123-update", delay: "5s", mode: "leading", // default }});```- **key**: Scoped to the task identifier- **delay**: How long to wait before executing (supports durationstrings like `"5s"`, `"1m"`)- **mode**: Either `"leading"` or `"trailing"`. Leading debounce willuse the payload and options from the first run created with the debouncekey. Trailing will use payload and options from the last run.### "trailing" mode overridesWhen using `mode: "trailing"` with debounce, the following options areupdated from the **last** trigger:- **`payload`** - The task input data- **`metadata`** - Run metadata- **`tags`** - Run tags (replaces existing tags)- **`maxAttempts`** - Maximum retry attempts- **`maxDuration`** - Maximum compute time- **`machine`** - Machine preset (cpu/memory)## Behavior- **First run wins**: The first trigger creates the run, subsequenttriggers push its execution time later- **Idempotency keys take precedence**: If both are specified,idempotency is checked first- **Max duration**: Configurable via `DEBOUNCE_MAX_DURATION_MS` env var(default: 10 minutes)Works with `triggerAndWait` - parent runs correctly block on thedebounced run.
Commits on Dec 19, 2025
feat(webapp): Add support for resetting idempotency keys (#2777)
Add support for resetting idempotency keys both from ui and sdk## ✅ Checklist- [x] I have followed every step in the [contributingguide](https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md)- [x] The PR title follows the convention.- [x] I ran and tested the code works---## Testing- Created a new run with a idempotency idempotencyKey.- Started a new run with the same task and got redirected to the firstrun.- Deleted the key from the UI on the run details- Started a new run with the same task and it created a new one- Did the above steps using the SDK---## Changelog- Add new action route for resetting idempotency keys via UI- Add reset button in Idempotency section of run detail view- Added API and SDK for resetting imdepotency- Updated docs page for this feature---## Screenshots_[Screenshots]_<img width="438" height="363" alt="Screenshot 2025-12-11 at 11 56 37"src="https://github.com/user-attachments/assets/30b8ef5e-8aac-4d04-b57a-9bf30d085dcb"/>
fix(webapp): Make spans fluid again while task is executing (#2801)
Closes #<issue>## ✅ Checklist- [x] I have followed every step in the [contributingguide](https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md)- [x] The PR title follows the convention.- [x] I ran and tested the code works---## TestingTested on executing tasks and on moving between tasks---## ChangelogSmall UI fix for spans on the task runs page---## Screenshotshttps://github.com/user-attachments/assets/72095b03-c74f-4472-afde-9c63e6e7c224💯
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:git diff @trigger.dev/sdk@4.3.0...main
Uh oh!
There was an error while loading.Please reload this page.