Spec gap: buffer operator behavior when both count and time are specified is undefined #17

Open
opened 2026-05-27 05:26:31 +00:00 by hurui200320 · 0 comments
Member

Problem

§5.3.2 shows count and time as alternative parameters for the buffer operator, using # OR in the YAML comments:

- type: buffer
  params:
    count: <integer>             # Emit every N messages
    timeout: <number>            # Optional max wait, in seconds (default 0.1)
    # OR
    time: <number>               # Buffer for N seconds and flush

However, there is no specification for what happens if a user provides both count and time in the same buffer operator. The options are:

  1. ConfigurationError: Reject at load time as an invalid combination.
  2. count wins: Use count-based buffering, ignore time.
  3. time wins: Use time-based buffering, ignore count.
  4. Either trigger flushes: Buffer flushes when either count messages accumulate OR time seconds pass — whichever comes first.

Option 4 is arguably the most useful semantics (and common in reactive stream libraries), but it needs to be explicitly specified rather than left to the implementor.

Fix Needed

Add a sentence to the buffer operator definition specifying the behavior when both count and time are provided.

References

  • §5.3.2 — buffer operator
## Problem §5.3.2 shows `count` and `time` as alternative parameters for the `buffer` operator, using `# OR` in the YAML comments: ```yaml - type: buffer params: count: <integer> # Emit every N messages timeout: <number> # Optional max wait, in seconds (default 0.1) # OR time: <number> # Buffer for N seconds and flush ``` However, there is no specification for what happens if a user provides **both** `count` and `time` in the same `buffer` operator. The options are: 1. **`ConfigurationError`**: Reject at load time as an invalid combination. 2. **`count` wins**: Use `count`-based buffering, ignore `time`. 3. **`time` wins**: Use `time`-based buffering, ignore `count`. 4. **Either trigger flushes**: Buffer flushes when either `count` messages accumulate OR `time` seconds pass — whichever comes first. Option 4 is arguably the most useful semantics (and common in reactive stream libraries), but it needs to be explicitly specified rather than left to the implementor. ## Fix Needed Add a sentence to the `buffer` operator definition specifying the behavior when both `count` and `time` are provided. ## References - §5.3.2 — `buffer` operator
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cleveragents/actors-spec#17
No description provided.