Debouncing

[juanpmarin]

Thanks & Kudos
Huge thanks to the River team for crafting such a versatile job-processing engine!

What is debouncing?
Debouncing batches a rapid sequence of events into a single action after a specified “quiet” interval—only the final event in a burst triggers processing.

High-level use case
In a conversational system, users often send multiple messages in quick succession. We want to defer work until the conversation pauses, then invoke our chatbot once with the latest context. Is it possible to implement this with river?

[juanpmarin]

Systems like inngest, natively support this pattern:
https://www.inngest.com/docs/guides/debounce

[bgentry]

I believe #550 and #453 were previous discussions of this kind of feature ("batching" or "aggregation"). We got pretty close on an early implementation for one approach here but decided to change directions and haven't come back around to it. Definitely would be useful to have!

I wanted to confirm some more details about your use case @juanpmarin. What time frame are you looking to aggregate over? We kicked around ideas for a couple approaches, one of which essentially batched jobs already on the queue, and another which allowed a configurable (longer) period to delay processing certain jobs for the sake of efficiency. It sounds like you were probably thinking of the latter?

[juanpmarin]

Thanks for digging into this!

I’m looking to delay processing per conversation over a short, configurable window—typically on the order of 5–15 seconds.. The goal is not to batch every job on the queue, but to hold each conversation’s work for that “quiet” interval so that rapid-fire messages collapse into a single job with the latest context.

So yes—it’s the latter approach: a tunable delay per job (conversation) rather than post-queue aggregation.