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)
Values
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.