Skip to content

Conversation

@alecmerdler
Copy link
Contributor

@alecmerdler alecmerdler commented Oct 18, 2025

Adds the spillover boolean field to the memory buffer component (default false). When true, any incoming message batch that will put the buffer above its configured limit will be dropped.

The motivation for this is to support input sources that do not gracefully handle backpressure and where the desired delivery guarantees are best effort.

Resolves #509

@alecmerdler alecmerdler force-pushed the memory-buffer-spillover branch from e4ec353 to 16fe1d0 Compare October 18, 2025 13:30
@alecmerdler alecmerdler changed the title feat(memory_buffer): allow buffer spillover feat(buffer_memory): allow buffer spillover Oct 18, 2025

for (m.bytes + extraBytes) > m.cap {
if m.spilloverEnabled {
return component.ErrMessageTooLarge
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can introduce a new error type for spillover, if that makes sense.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think it would be better to add a different error message - will be easier to debug too.

Copy link
Contributor Author

@alecmerdler alecmerdler Oct 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in e36405d and rebased.

@gregfurman gregfurman self-assigned this Oct 20, 2025
@alecmerdler
Copy link
Contributor Author

@gregfurman @jem-davies Any thoughts on this approach? I'm happy to make any changes.

Adds the 'spillover' boolean field to the
'memory' buffer component (default false). When
true, any incoming message batch that will put
the buffer above its configured 'limit' will be
dropped.

The motivation for this is to support input
sources that do not gracefully handle
backpressure and where the desired delivery
guarantees are best effort.
@alecmerdler alecmerdler force-pushed the memory-buffer-spillover branch from 16fe1d0 to 2dafcb5 Compare October 21, 2025 13:08
@alecmerdler alecmerdler force-pushed the memory-buffer-spillover branch from 2dafcb5 to e36405d Compare October 21, 2025 14:00
@alecmerdler
Copy link
Contributor Author

Fixed the tests

@gregfurman
Copy link
Collaborator

@alecmerdler 👋 Thanks for the contribution!

While I'll give this proper review a bit later today, this PR got thinking whether the buffer component could perhaps be a bit too limited, and whether extending it to support conditional buffering could be a useful approach. For example:

buffer:
  memory:
    limit: 1000
  drop_on:
    - check: this.errored()
    - check: this == ""
    # etc ...

Could be over-engineering but am curious to hear your thoughts 🤔

@alecmerdler
Copy link
Contributor Author

Adding conditional buffering does seem like overkill and starts to mix concerns. What's missing for my use case is having any layer between inputs and buffers where we could drop on backpressure.

Either way, since the memory buffer allows configuring the limit, I believe it makes sense to expose a parameter that let's you choose what happens when that limit is reached.

Copy link
Collaborator

@gregfurman gregfurman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Will give some more thought on how we can extend the buffer component but agree adding this spillover flag makes sense 👍

@gregfurman gregfurman merged commit f56fc96 into warpstreamlabs:main Oct 22, 2025
3 checks passed
@alecmerdler alecmerdler deleted the memory-buffer-spillover branch October 23, 2025 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Spillover mechanism for memory buffer

3 participants