Struct ConsumeResponse 

pub struct ConsumeResponse {
    pub events: Vec<StoredEvent>,
    pub next_id: Option<String>,
    pub has_more: bool,
    pub truncated_at_per_shard_cap: bool,
    pub stalled_shards: Vec<u16>,
    pub failed_shards: Vec<u16>,
}

Response from consuming events.

Fields

events: Vec<StoredEvent>

Events matching the request.

next_id: Option<String>

Cursor for the next poll. None if no events returned.

has_more: bool

True if there are more events available.

truncated_at_per_shard_cap: bool

true if the per-shard fetch was clamped by the internal PER_SHARD_FETCH_CAP (10 000). Callers requesting very large limit values across few shards may receive fewer events than limit per poll() even when the underlying streams have more — pagination via next_id still works.

Pre-fix this clamp was silent. The default is false; tools building observability around large polls can detect under-delivery via this flag.

stalled_shards: Vec<u16>

Shards that reported has_more=true but contributed no events and no cursor advance to this poll. The merger suppresses the aggregate has_more flag for caller- protection (preventing infinite loops), but operators monitoring adapter health should know which shards are stuck.

Pre-fix the suppression was logged at warn but invisible to callers. Empty on the happy path; populated only when a stall was detected and suppressed.

failed_shards: Vec<u16>

Shards whose adapter call returned an error during this poll. The merger logs each error at WARN and continues with the surviving shards, so the response’s events can come from a strict subset of the configured shards and silently miss data the operator expected to see. Operators monitoring adapter health need to know WHICH shards failed (not just that something logged a warn) so they can correlate alerts with specific Redis / JetStream nodes.

Pre-fix this signal lived only in the warn log; an observer parsing ConsumeResponse saw a clean partial- shards response with no field indicating which shards were missing, in contrast to stalled_shards which IS surfaced. Empty on the happy path; populated only when at least one shard’s poll errored.

Recovery-latency note: when a previously-failed shard returns to health, its backlog drains at the per-shard limit of the next poll (limit / shards.len() * over_fetch_factor). A 4-shard poll where one shard was down for 60 s and the others kept ingesting can take several normal-cadence polls to fully drain the recovered shard. No backlog-size hint is surfaced on the response; callers that need to detect a stuck-recovery condition should monitor cursor advance per shard across consecutive polls.

Implementations

impl ConsumeResponse

pub fn empty() -> Self

Create an empty response.

Trait Implementations

impl Clone for ConsumeResponse

fn clone(&self) -> ConsumeResponse

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ConsumeResponse

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.