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
fix(webapp,run-engine,core): raise the debounce ceiling to 24h and reject windows that cannot debounce
A debounced run is only pushed later while the new execution time stays
inside maxDelay (or the server maximum) measured from the first trigger,
so the room to push is the gap between the two. A delay at or above that
ceiling meant the first extension was already out of bounds: every
trigger created its own run, with no error and nothing on the run to
show the debounce had been ignored.
The default ceiling moves from 1 hour to 24 hours, and a delay that
leaves no room is now rejected at trigger time with a message naming
both values and how to fix them. debounce.delay must also be a duration
rather than a date, since it is re-applied on every extension.
Debounce windows can now run up to 24 hours by default, and a `debounce.delay` that leaves no room to extend the run is rejected instead of silently doing nothing.
6
+
7
+
A debounced run is only pushed later while its new execution time stays inside `maxDelay` (or the server maximum) measured from the first trigger, so the room you have to push is `maxDelay` minus `delay`. Setting a `delay` at or above that ceiling previously meant every trigger created its own run, with no error and nothing on the run to show the debounce had been ignored. Those triggers now fail with a message naming both values and how to fix them.
Copy file name to clipboardExpand all lines: docs/triggering.mdx
+36-2Lines changed: 36 additions & 2 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`. Defaults to the maximum debounce duration, which is 24 hours on Trigger.dev Cloud
877
877
878
878
**How it works:**
879
879
@@ -882,9 +882,43 @@ 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
+
**Your delay must fit inside the maximum:**
886
+
887
+
A run can only be pushed later while its new execution time stays inside `maxDelay`, measured from the first trigger. The room you have to push is therefore `maxDelay` minus `delay`. With `delay: "5s"` and the 24 hour default, a key can be pushed for almost a full day. With `delay: "24h"` and no `maxDelay`, there is no room at all: the first push is already out of bounds, so every trigger would create its own run.
888
+
889
+
Triggers like that are rejected rather than silently behaving as if you had not set a debounce:
890
+
891
+
```
892
+
debounce.delay (24h) is at or above the maximum debounce duration of 1d. A debounced run
893
+
can only be extended while it is inside that window, so with this delay every trigger would
894
+
create its own run. Either shorten the delay, or set debounce.maxDelay above 24h to raise
895
+
the ceiling for this trigger.
896
+
```
897
+
898
+
To debounce for longer than 24 hours, set `maxDelay` above your `delay`:
899
+
900
+
```ts
901
+
awaitmyTask.trigger(
902
+
{ conversationId: "123" },
903
+
{
904
+
debounce: {
905
+
key: "conversation-123",
906
+
delay: "12h", // Wait 12h after each trigger
907
+
maxDelay: "36h", // Keep extending for up to 36h from the first trigger
908
+
},
909
+
}
910
+
);
911
+
```
912
+
913
+
<Warning>
914
+
`delay` must be a duration string, not a date. A date is accepted by the `delay` option on a
915
+
normal trigger, but `debounce.delay` is re-applied every time the run is pushed later, so it has
916
+
to be relative.
917
+
</Warning>
918
+
885
919
**Limiting total delay with `maxDelay`:**
886
920
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.
921
+
The `maxDelay` option sets an upper bound on the total delay from the first trigger, ensuring the run eventually executes even with constant activity.
0 commit comments