You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/upgrade-to-v4.mdx
+85-25Lines changed: 85 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -749,40 +749,50 @@ await myTask.trigger({ foo: "bar" }); // Will use the queue defined on the task
749
749
awaitmyTask2.trigger({ foo: "bar" }); // Will use the queue defined on the task
750
750
```
751
751
752
-
### Releasing concurrency on waits
752
+
### Concurrency changes
753
753
754
-
We've changed the default behavior on how concurrency is released when a run is paused or resumed because of a wait. Previously, the concurrency would be released immediately when the run was first paused, no matter the settings on the queue.
754
+
We've changed a few things around how concurrency is managed at the environment and queue level:
755
755
756
-
Now we will no longer release concurrency on a queue that has a specified `concurrencyLimit` when a run is paused. You can go back to the previous behavior by setting the `releaseConcurrencyOnWaitpoint` option to `true` on the queue:
756
+
- Environment concurrency limits are now "burstable" above the base concurrency limit. The default burst factor is 2.0, meaning that the environment concurrency limit can be up to 2x the base concurrency limit. So if your base concurrency limit is 10, the environment concurrency limit can be up to 20.
757
+
- Each individual queue has a maximum concurrency limit of the environment base concurrency limit, NOT the burstable limit. So if your base concurrency limit is 10, the queue concurrency limit can be up to 10. This means if you don't set the queue concurrency limit, it will default to the environment base concurrency limit.
758
+
- The only time we "release" concurrency is when a run is checkpointed. This means that if you have a run that is waiting on a waitpoint, and the run is checkpointed, the concurrency will be released back into the queue, allowing other runs to execute/resume. We release the concurrency back to the queue and the environment.
757
759
758
-
```ts
759
-
const myQueue =queue({
760
-
name: "my-queue",
761
-
concurrencyLimit: 10,
762
-
releaseConcurrencyOnWaitpoint: true,
763
-
});
764
-
```
760
+
This means that if you have a queue with a `concurrencyLimit` of 1, you can only have exactly 1 run executing at a time, but you may have more than 1 run in the `WAITING` state that belongs to that queue. Runs are only transitioned to the `WAITING` state when they are waiting on a waitpoint and have been checkpointed.
765
761
766
-
You can also now control whether concurrency is released when performing a wait:
762
+
### New Run Statuses
767
763
768
-
```ts
769
-
// This will prevent the run from being released back into the queue when the wait starts
We've done some work cleaning up the run statuses. The new statuses are:
772
765
773
-
The new default behavior allows you to ensure that you can control the number of executing & waiting runs on a queue, and guarantee runs will resume once they are meant to be resumed.
766
+
-`PENDING_VERSION`: Task is waiting for a version update because it cannot execute without additional information (task, queue, etc.).
767
+
-`QUEUED`: Task is waiting to be executed by a worker.
768
+
-`DEQUEUED`: Task has been dequeued and is being sent to a worker to start executing.
769
+
-`EXECUTING`: Task is currently being executed by a worker.
770
+
-`WAITING`: Task has been paused by the system, and will be resumed by the system.
771
+
-`COMPLETED`: Task has been completed successfully.
772
+
-`CANCELED`: Task has been canceled by the user.
773
+
-`FAILED`: Task has failed to complete, due to an error in the task code.
774
+
-`CRASHED`: Task has crashed and won't be retried, most likely the worker ran out of resources, e.g. memory or storage.
775
+
-`SYSTEM_FAILURE`: Task has failed to complete, due to an error in the system
776
+
-`DELAYED`: Task has been scheduled to run at a specific time.
777
+
-`EXPIRED`: Task has expired and won't be executed,
778
+
-`TIMED_OUT`: Task has reached its maxDuration and has been stopped.
774
779
775
-
<Note>
776
-
If you do choose to release concurrency on waits, be aware that it's possible a resume is delayed
777
-
if the concurrency that was released is not available at the time the wait completes. In this
778
-
case, the run will go back into the queue and will resume once concurrency becomes available.
779
-
</Note>
780
+
We've removed the following statuses:
780
781
781
-
This new behavior effects all the wait functions:
782
+
-`WAITING_FOR_DEPLOY`: This is no longer used, and is replaced by `PENDING_VERSION`
783
+
-`FROZEN`: This is no longer used, and is replaced by `WAITING`
784
+
-`INTERRUPTED`: This is no longer used
785
+
-`REATTEMPTING`: This is no longer used, and is replaced by `EXECUTING`
782
786
783
-
- Wait for duration (e.g. `wait.for({ seconds: 10 })`)
784
-
- Wait for a child task to complete (e.g. `myTask.triggerAndWait()`, `myTask.batchTriggerAndWait([...])`)
785
-
- Wait for a token to complete (e.g. `wait.forToken(tokenId)`)
787
+
We've also added "boolean" helpers to runs returned via the API and from Realtime:
788
+
789
+
-`isQueued`: Returns true when the status is `QUEUED`, `PENDING_VERSION`, or `DELAYED`
790
+
-`isExecuting`: Returns true when the status is `EXECUTING`, `DEQUEUED`. These count against your concurrency limits.
791
+
-`isWaiting`: Returns true when the status is `WAITING`. These do not count against your concurrency limits.
792
+
-`isCompleted`: Returns true when the status is any of the completed statuses.
793
+
-`isCanceled`: Returns true when the status is `CANCELED`
794
+
-`isFailed`: Returns true when the status is any of the failed statuses.
795
+
-`isSuccess`: Returns true when the status is `COMPLETED`
786
796
787
797
### Lifecycle hooks
788
798
@@ -1115,3 +1125,53 @@ We recommend enabling this option and testing in a staging or preview environmen
1115
1125
- Fail fast in CI when running deploy with missing `TRIGGER_ACCESS_TOKEN` and add useful error message with link to docs ([#2258](https://github.com/triggerdotdev/trigger.dev/pull/2258))
- Removes the `releaseConcurrencyOnWaitpoint` option on queues and the `releaseConcurrency` option on various wait functions. Replaced with the following default behavior: ([#2284](https://github.com/triggerdotdev/trigger.dev/pull/2284))
1134
+
1135
+
- Concurrency is never released when a run is first blocked via a waitpoint, at either the env or queue level.
1136
+
- Concurrency is always released when a run is checkpointed and shutdown, at both the env and queue level.
1137
+
1138
+
Additionally, environment concurrency limits now have a new "Burst Factor", defaulting to 2.0x. The "Burst Factor" allows the environment-wide concurrency limit to be higher than any individual queue's concurrency limit. For example, if you have an environment concurrency limit of 100, and a Burst Factor of 2.0x, then you can execute up to 200 runs concurrently, but any one task/queue can still only execute 100 runs concurrently.
1139
+
1140
+
We've done some work cleaning up the run statuses. The new statuses are:
1141
+
1142
+
-`PENDING_VERSION`: Task is waiting for a version update because it cannot execute without additional information (task, queue, etc.)
1143
+
-`QUEUED`: Task is waiting to be executed by a worker
1144
+
-`DEQUEUED`: Task has been dequeued and is being sent to a worker to start executing.
1145
+
-`EXECUTING`: Task is currently being executed by a worker
1146
+
-`WAITING`: Task has been paused by the system, and will be resumed by the system
1147
+
-`COMPLETED`: Task has been completed successfully
1148
+
-`CANCELED`: Task has been canceled by the user
1149
+
-`FAILED`: Task has failed to complete, due to an error in the system
1150
+
-`CRASHED`: Task has crashed and won't be retried, most likely the worker ran out of resources, e.g. memory or storage
1151
+
-`SYSTEM_FAILURE`: Task has failed to complete, due to an error in the system
1152
+
-`DELAYED`: Task has been scheduled to run at a specific time
1153
+
-`EXPIRED`: Task has expired and won't be executed
1154
+
-`TIMED_OUT`: Task has reached it's maxDuration and has been stopped
1155
+
1156
+
We've removed the following statuses:
1157
+
1158
+
-`WAITING_FOR_DEPLOY`: This is no longer used, and is replaced by `PENDING_VERSION`
1159
+
-`FROZEN`: This is no longer used, and is replaced by `WAITING`
1160
+
-`INTERRUPTED`: This is no longer used
1161
+
-`REATTEMPTING`: This is no longer used, and is replaced by `EXECUTING`
1162
+
1163
+
We've also added "boolean" helpers to runs returned via the API and from Realtime:
1164
+
1165
+
-`isQueued`: Returns true when the status is `QUEUED`, `PENDING_VERSION`, or `DELAYED`
1166
+
-`isExecuting`: Returns true when the status is `EXECUTING`, `DEQUEUED`. These count against your concurrency limits.
1167
+
-`isWaiting`: Returns true when the status is `WAITING`. These do not count against your concurrency limits.
1168
+
-`isCompleted`: Returns true when the status is any of the completed statuses.
1169
+
-`isCanceled`: Returns true when the status is `CANCELED`
1170
+
-`isFailed`: Returns true when the status is any of the failed statuses.
1171
+
-`isSuccess`: Returns true when the status is `COMPLETED`
1172
+
1173
+
This change adds the ability to easily detect which runs are being counted against your concurrency limit by filtering for both `EXECUTING` or `DEQUEUED`.
1174
+
1175
+
- Added runs.list filtering for queue and machine ([#2277](https://github.com/triggerdotdev/trigger.dev/pull/2277))
0 commit comments