MessageBufferConfig

Configuration for buffering inbound NewMessageEvents for specific channel types before they are dispatched to the sequential event-handling pipeline.

High-traffic channel types (e.g. livestreams) can produce a flood of new-message events that arrive faster than they can be processed sequentially. This configuration applies a bounded buffer with a configurable overflow strategy (e.g. drop oldest) for NewMessageEvents on the configured channel types only. Events for other channel types — and all non-NewMessageEvent events — continue to flow through the default unbuffered path with Int.MAX_VALUE capacity, so signal-critical events such as reads, bans or member updates are never dropped.

By default this is a no-op: no channel types are configured, so the buffered code path is not active and the SDK behaves exactly as if this configuration did not exist.

Event ordering caveat. When buffering is active, NewMessageEvents for opted-in channel types flow through a separate buffer from all other events. As a consequence, the relative ordering between buffered NewMessageEvents and non-buffered events (e.g. ReactionNewEvent, MessageUpdatedEvent) for the same channel is not guaranteed — a reaction added to message X may be processed before the NewMessageEvent for X. Because this configuration already tolerates dropping events on overflow, callers opting in are expected to tolerate this consistency relaxation as well.

Example — drop the oldest pending NewMessageEvent for messaging channels when more than 100 are queued:

ChatClientConfig(
    messageLimitConfig = MessageLimitConfig(
        messageBufferConfig = MessageBufferConfig(
            channelTypes = setOf("messaging"),
            capacity = 100,
            overflow = MessageBufferOverflow.DROP_OLDEST,
        ),
    ),
)

Parameters