ssevents/limit

Parser and decoder safety limits.

These values bound memory growth for the incremental decoder. The new constructor rejects nonsensical values with a panic so callers do not silently run with ineffective limits. For dynamic input (config / env / framework), use new_checked and surface LimitConfigError.NonPositiveLimit through your normal result chain.

Types

Why a checked limit constructor refused its argument.

field names the offending parameter so a single handler can produce meaningful diagnostics across many checked constructors; given carries the rejected value.

pub type LimitConfigError {
  NonPositiveLimit(field: String, given: Int)
}

Constructors

  • NonPositiveLimit(field: String, given: Int)
pub opaque type Limits

Values

pub fn default() -> Limits
pub const default_max_data_lines: Int
pub const default_max_event_bytes: Int
pub const default_max_line_bytes: Int
pub const default_max_retry_value: Int
pub fn max_data_lines(limits: Limits) -> Int
pub fn max_event_bytes(limits: Limits) -> Int
pub fn max_line_bytes(limits: Limits) -> Int
pub fn max_retry_value(limits: Limits) -> Int
pub fn new(
  max_line_bytes max_line_bytes: Int,
  max_event_bytes max_event_bytes: Int,
  max_data_lines max_data_lines: Int,
  max_retry_value max_retry_value: Int,
) -> Limits
pub fn new_checked(
  max_line_bytes max_line_bytes: Int,
  max_event_bytes max_event_bytes: Int,
  max_data_lines max_data_lines: Int,
  max_retry_value max_retry_value: Int,
) -> Result(Limits, LimitConfigError)

Like new, but returns the argument-validation failure as a Result instead of panicking. Use this when limit values come from configuration, environment variables, or other dynamic sources where a malformed value is a recoverable runtime condition rather than a programmer error.

On success the returned Limits is identical to what new would return for the same arguments.

Search Document