Problem Statement
A very common user behaviour on chat platforms is sending a burst of messages in quick succession — typing a thought across three short lines, forwarding a batch of links, or firing off follow-up questions before the first has been read. Any assistant-style bot built on chat-sdk wants to treat this as one logical turn: read everything the user just sent, respond once.
Proposed Solution
Introduce 'queue-debounce' — like 'queue', but the FIRST message in an idle thread also waits debounceMs so a burst that arrives while the lock is free collapses into a single handler invocation. The handler receives the latest message with context.skipped containing the rest of the burst. Subsequent bursts arriving while the handler is running collapse via the same queue drain mechanism.
Alternatives Considered
Neither existing concurrency strategy expresses this cleanly:
"queue" — msg 1 acquires the lock and dispatches its handler immediately. By the time msgs 2 and 3 land, the handler is already running; they enqueue and drain together after msg 1 finishes (message = msg3, context.skipped = [msg2]). The user gets two handler invocations for one burst: the bot replies to the first sentence, then a second reply for the rest. Reads as "bot answered before I finished typing."
"debounce" — collapses the burst at idle correctly but only the last message in the window dispatches.
Use Case
const chat = new Chat({
adapters: {
//...
},
state: opts.state,
// `queue-debounce` first message on an idle thread waits `debounceMs` so a
// burst landing in that window collapses into one handler call with
// `context.skipped` populated. Subsequent bursts arriving mid-handler drain
// through the normal queue path — no orphan bug like pure `debounce`. Lets
// the agent respond to "three messages in 1s" as one turn instead of 1 | 2+3.
// Cost: +1s baseline latency on every DM, including lone messages.
// Acceptable for an assistant.
concurrency: { strategy: "queue-debounce", debounceMs: 1000 },
userName: "openxyz",
logger: "info",
});
Priority
Critical
Contribution
Additional Context
No response
Problem Statement
A very common user behaviour on chat platforms is sending a burst of messages in quick succession — typing a thought across three short lines, forwarding a batch of links, or firing off follow-up questions before the first has been read. Any assistant-style bot built on chat-sdk wants to treat this as one logical turn: read everything the user just sent, respond once.
Proposed Solution
Introduce
'queue-debounce'— like'queue', but the FIRST message in an idle thread also waitsdebounceMsso a burst that arrives while the lock is free collapses into a single handler invocation. The handler receives the latest message withcontext.skippedcontaining the rest of the burst. Subsequent bursts arriving while the handler is running collapse via the samequeuedrain mechanism.Alternatives Considered
Neither existing concurrency strategy expresses this cleanly:
"queue"— msg 1 acquires the lock and dispatches its handler immediately. By the time msgs 2 and 3 land, the handler is already running; they enqueue and drain together after msg 1 finishes (message = msg3,context.skipped = [msg2]). The user gets two handler invocations for one burst: the bot replies to the first sentence, then a second reply for the rest. Reads as "bot answered before I finished typing.""debounce"— collapses the burst at idle correctly but only the last message in the window dispatches.Use Case
Priority
Critical
Contribution
Additional Context
No response