Eric Allam
26093896d2
* Fixes various issues with triggerAndWait and batchTriggerAndWait When using idempotency keys, triggerAndWait and batchTriggerAndWait will still work even if the existing runs have already been completed (or even partially completed, in the case of batchTriggerAndWait) - TaskRunExecutionResult.id is now the run friendlyId, not the attempt friendlyId - A single TaskRun can now have many batchItems, in the case of batchTriggerAndWait while using idempotency keys - A run’s idempotencyKey is now added to the ctx as well as the TaskEvent and displayed in the span view - When resolving batchTriggerAndWait, the runtimes no longer reject promises, leading to an error in the parent task * Remove the default queue concurrency limit as we now have env and org concurrency limits * Use the run friendlyId in the completion result id * Added some error logging
708 B
708 B
@trigger.dev/sdk, trigger.dev, @trigger.dev/core
| @trigger.dev/sdk | trigger.dev | @trigger.dev/core |
|---|---|---|
| patch | patch | patch |
When using idempotency keys, triggerAndWait and batchTriggerAndWait will still work even if the existing runs have already been completed (or even partially completed, in the case of batchTriggerAndWait)
- TaskRunExecutionResult.id is now the run friendlyId, not the attempt friendlyId
- A single TaskRun can now have many batchItems, in the case of batchTriggerAndWait while using idempotency keys
- A run’s idempotencyKey is now added to the ctx as well as the TaskEvent and displayed in the span view
- When resolving batchTriggerAndWait, the runtimes no longer reject promises, leading to an error in the parent task