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/triggering.mdx
+16-4Lines changed: 16 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -873,7 +873,7 @@ The `debounce` option accepts:
873
873
-`key` - A unique string to identify the debounce group (scoped to the task)
874
874
-`delay` - Duration string specifying how long to delay. Supported units: `s` (seconds), `m` (minutes), `h`/`hr` (hours), `d` (days), `w` (weeks). Minimum is 1 second. Examples: `"5s"`, `"1m"`, `"2h30m"`
875
875
-`mode` - Optional. Controls which trigger's data is used: `"leading"` (default) or `"trailing"`
876
-
-`maxDelay` - Optional. Maximum total time from the first trigger before the run must execute. Uses the same duration format as `delay`
876
+
-`maxDelay` - Optional. Maximum total time from the first trigger before the run must execute. Uses the same duration format as `delay`. Not set by default
877
877
878
878
**How it works:**
879
879
@@ -882,9 +882,18 @@ The `debounce` option accepts:
882
882
3. Once no new triggers occur within the delay duration, the run executes
883
883
4. After the run starts executing, a new trigger with the same key will create a new run
884
884
885
+
<Warning>
886
+
There is no time limit on step 2. While triggers keep arriving on the same key, the run keeps
887
+
being pushed back and never executes. A key triggered every 10 seconds with a `delay` of `"30s"`
888
+
runs 30 seconds after the triggers stop, however long that takes. Set `maxDelay` whenever the
889
+
work needs to happen eventually. This matters most with `triggerAndWait`: every parent waiting
890
+
on a debounced run stays blocked, and holds its concurrency, for as long as the run keeps being
891
+
pushed back.
892
+
</Warning>
893
+
885
894
**Limiting total delay with `maxDelay`:**
886
895
887
-
By default, continuous triggers can delay execution indefinitely. The `maxDelay` option sets an upper bound on the total delay from the first trigger, ensuring the run eventually executes even with constant activity.
896
+
The `maxDelay` option sets an upper bound on the total delay from the first trigger, ensuring the run eventually executes even with constant activity.
888
897
889
898
```ts
890
899
awaitsummarizeChat.trigger(
@@ -921,11 +930,14 @@ Consider `delay: "5s"` and `maxDelay: "30s"` with triggers arriving every 2 seco
921
930
922
931
Without `maxDelay`, continuous triggers would prevent the run from ever executing. With `maxDelay: "30s"`, execution is guaranteed within 30 seconds of the first trigger.
923
932
933
+
Keep `delay` well below `maxDelay`. A run is only pushed back while its new execution time stays inside `maxDelay`, so the room you have to push is `maxDelay` minus `delay`. Setting them equal, or setting `delay` higher, leaves no room at all, and the trigger is rejected rather than accepted as a debounce that could never collapse anything.
934
+
924
935
<Note>
925
936
The `maxDelay` value is evaluated from each trigger call, not stored with the original run. This
926
937
means if you pass different `maxDelay` values for the same debounce key, each trigger uses its own
927
-
`maxDelay` to check against the original run's creation time. For consistent behavior, use the
928
-
same `maxDelay` value for all triggers with the same debounce key.
938
+
`maxDelay` to check against the original run's creation time. A trigger that omits `maxDelay`
939
+
has no bound at all, so a single call without it can push the run past the limit the other calls
940
+
set. Use the same `maxDelay` value for every trigger with the same debounce key.
0 commit comments