Event Rate Limit Acceptance Trace
Trace sliding-window rate limits over accepted events in (t−window,t]; rejected events do not consume acceptance capacity.
Description
Trace sliding-window rate limits over accepted events in (t−window,t]; rejected events do not consume acceptance capacity.
A rolling rate limit can count accepted events within a moving time window. The precise open boundary determines whether an old event still occupies capacity.
When to use this tool
Trace sliding-window rate limits over accepted events in (t−window,t]; rejected events do not consume acceptance capacity.
- Prepare the supplied eventTimes, windowDuration, maximumAccepted 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, windowDuration, maximumAccepted. 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, result.acceptance. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
Process nondecreasing times. At time t, count previously accepted events whose times are strictly greater than t-windowDuration; accept the current event only if that count is below maximumAccepted.1
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| eventTimes | event times. | List of finite numbers; bounded by the operation |
| windowDuration | window duration. | Finite number; greater than zero |
| maximumAccepted | maximum accepted. | Integer from 1 to 10000 inclusive |
| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.acceptedIndexes | The accepted indexes list in the ordering and representation described above. |
| result.acceptance | The acceptance list in the ordering and representation described above. |
{
"input": {
"eventTimes": [
0,
1,
2,
5
],
"windowDuration": 3,
"maximumAccepted": 2
},
"output": {
"result": {
"acceptedIndexes": [
0,
1,
3
],
"acceptance": [
true,
true,
false,
true
]
}
}
}Limitations and assumptions
- The window excludes its left boundary. Rejected events consume no capacity, and equal-time events are considered in input order. This is a rolling accepted-event model rather than a token bucket.
- 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 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.
- 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.