Event Cooldown Acceptance Trace
Accept the first event and later events at least the caller cooldown after the last accepted event; rejected events do not restart the cooldown.
Description
Accept the first event and later events at least the caller cooldown after the last accepted event; rejected events do not restart the cooldown.
A cooldown accepts an event only after enough time has elapsed since the last accepted event. Rejected events do not necessarily restart that cooldown.
When to use this tool
Accept the first event and later events at least the caller cooldown after the last accepted event; rejected events do not restart the cooldown.
- Prepare the supplied eventTimes, cooldown fields for this operation.
- Compare the complete example with the representation used by your own input before carrying the result into another step.
How to use the tool and how it works
- Enter eventTimes, cooldown. Use the exact text syntax, units and index conventions explained below.
- Run the tool. If input validation fails, correct the supplied fields before interpreting any result.
- Read result.acceptedIndexes. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
Process nondecreasing event times in input order. Accept the first event, then accept a time exactly when it is at least cooldown after the last accepted time; return the accepted indexes.1
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| eventTimes | event times. | List of finite numbers; bounded by the operation |
| cooldown | cooldown. | Finite number; zero or greater |
| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.acceptedIndexes | The accepted indexes list in the ordering and representation described above. |
{
"input": {
"eventTimes": [
0,
1,
2,
5
],
"cooldown": 2
},
"output": {
"result": {
"acceptedIndexes": [
0,
2,
3
]
}
}
}Limitations and assumptions
- Rejected events do not extend the waiting period. With zero cooldown, equal-time events all pass. This evaluates supplied events offline rather than scheduling live work.
- Every declared top-level field is required and unexpected fields are rejected. Numeric inputs must be finite; ordinary text fields are bounded to 8,192 UTF-16 code units, with tighter operation-specific limits where stated.
- Ordinary string lists have at most 128 entries of at most 128 code units each; numeric lists and matrices have separate bounded size checks. Nonfinite results and excessively large serialized outputs are rejected.
- Indexes are zero-based and spans have an exclusive end unless explicitly stated otherwise. A valid false, null or empty-list result is distinct from malformed input.
Alternative or Complementary methods
Choose a sampling model before combining results. Earlier-sample hold, linear interpolation and index-only differences answer different questions; event cooldown, debounce and rolling limits also use different acceptance rules.
References
Similar or alternative tools
- Event Rate Limit Acceptance Trace
Trace sliding-window rate limits over accepted events in (t−window,t]; rejected events do not consume acceptance capacity.
- Event Debounce Window Filter
Plan trailing-edge debounce emissions: retain the last event of each burst separated by strictly more than the quiet window; assumes no future events after the supplied list.