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): drop the hidden debounce ceiling, fail fast on an unusable maxDelay
The engine applied a server-side ceiling on how long a debounced run
could be pushed back, defaulting to an hour and documented nowhere. Any
delay at or above it could never push its run, so every trigger created
its own run with no error and nothing on the run to show the debounce
key had been ignored.
The ceiling is now unset by default, so a key keeps collapsing triggers
for as long as they arrive and maxDelay is the only bound. Self-hosters
can still set one. Callers who pass a maxDelay that is not longer than
their delay hit the same dead end, so that pair is rejected at trigger
time rather than silently doing nothing.
Copy file name to clipboardExpand all lines: .changeset/debounce-max-duration.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,16 +2,16 @@
2
2
"@trigger.dev/core": patch
3
3
---
4
4
5
-
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.
5
+
Debouncing with a `delay` longer than an hour now works. A hidden server-side limit was releasing debounced runs after an hour, so any `delay`at or above that never got to push its run back at all: every trigger created its own run, with no error and nothing on the run to show the debounce key had been ignored.
6
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.
7
+
That limit is gone. A debounce key with no `maxDelay`now keeps pushing its run back for as long as triggers keep arriving, which means it never executes while they do. Set `maxDelay` when the work has to happen eventually, and keep `delay` well below it, since the room available to push is the gap between the two.
Copy file name to clipboardExpand all lines: docs/triggering.mdx
+7-32Lines changed: 7 additions & 32 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`. Defaults to the maximum debounce duration, which is 24 hours on Trigger.dev Cloud
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,38 +882,11 @@ 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
885
<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.
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.
917
890
</Warning>
918
891
919
892
**Limiting total delay with `maxDelay`:**
@@ -955,6 +928,8 @@ Consider `delay: "5s"` and `maxDelay: "30s"` with triggers arriving every 2 seco
955
928
956
929
Without `maxDelay`, continuous triggers would prevent the run from ever executing. With `maxDelay: "30s"`, execution is guaranteed within 30 seconds of the first trigger.
957
930
931
+
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: every trigger creates its own run and the debounce key has no effect.
932
+
958
933
<Note>
959
934
The `maxDelay` value is evaluated from each trigger call, not stored with the original run. This
960
935
means if you pass different `maxDelay` values for the same debounce key, each trigger uses its own
0 commit comments