Struct JmapError 

#[non_exhaustive]
pub struct JmapError {
    pub error_type: String,
    pub description: Option<String>,
    pub existing_id: Option<Id>,
    pub limit: Option<u64>,
}

JMAP method-level error, serializable for inclusion in methodResponses.

See RFC 8620 §3.6.2 for the standard error type strings. The JSON key is "type" (not "error_type") per RFC 8620.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

error_type: String

Error type string per RFC 8620 §3.6.2.

description: Option<String>

Human-readable description. Omitted from JSON when None.

existing_id: Option<Id>

The id of the existing record. Only set for "alreadyExists" (RFC 8620 §5.4 MUST).

limit: Option<u64>

Maximum maxChanges value the server will accept. Only set for "tooManyChanges" (RFC 8620 §9.6.1 MUST).

Implementations

impl JmapError

pub fn invalid_arguments(desc: impl Into<String>) -> Self

RFC 8620 §3.6.2 — “invalidArguments”

pub fn forbidden() -> Self

RFC 8620 §3.6.2 — “forbidden”

pub fn not_found() -> Self

RFC 8620 §5.3 — “notFound”

pub fn account_not_found() -> Self

RFC 8620 §5.1 — “accountNotFound”

pub fn account_not_supported_by_method() -> Self

RFC 8620 §5.1 — “accountNotSupportedByMethod”

pub fn account_read_only() -> Self

RFC 8620 §5.1 — “accountReadOnly”

pub fn server_unavailable() -> Self

RFC 8620 §3.6.2 — “serverUnavailable”

pub fn server_fail(desc: impl Into<String>) -> Self

RFC 8620 §3.6.2 — “serverFail”

pub fn server_partial_fail() -> Self

RFC 8620 §3.6.2 — “serverPartialFail”

pub fn unknown_method() -> Self

RFC 8620 §3.6.2 — “unknownMethod”

pub fn invalid_result_reference() -> Self

RFC 8620 §3.6.2 — “invalidResultReference”

pub fn cannot_calculate_changes() -> Self

RFC 8620 §5.2 and §5.6 — “cannotCalculateChanges”

pub fn state_mismatch() -> Self

RFC 8620 §5.3 — “stateMismatch”

pub fn too_large() -> Self

RFC 8620 §5.3 — “tooLarge”

pub fn request_too_large() -> Self

RFC 8620 §5.1 and §5.3 — “requestTooLarge”

pub fn over_quota() -> Self

RFC 8620 §5.3 — “overQuota”

pub fn rate_limit() -> Self

RFC 8620 §5.3 — “rateLimit”

pub fn invalid_patch() -> Self

RFC 8620 §5.3 — “invalidPatch”

pub fn will_destroy() -> Self

RFC 8620 §5.3 — “willDestroy”

pub fn invalid_properties() -> Self

RFC 8620 §5.3 — “invalidProperties”

pub fn singleton() -> Self

RFC 8620 §5.3 — “singleton”

pub fn unsupported_filter() -> Self

RFC 8620 §5.5 — “unsupportedFilter”

pub fn anchor_not_found() -> Self

RFC 8620 §5.5 — “anchorNotFound”

pub fn already_exists(existing_id: Id) -> Self

RFC 8620 §5.4 — “alreadyExists”

existing_id is the id of the record that already exists in the target account. Per RFC 8620 §5.4, this field MUST be present on the SetError object.

pub fn from_account_not_found() -> Self

RFC 8620 §5.4 — “fromAccountNotFound”

pub fn from_account_not_supported_by_method() -> Self

RFC 8620 §5.4 — “fromAccountNotSupportedByMethod”

pub fn unsupported_sort() -> Self

RFC 8620 §5.5 — “unsupportedSort”

pub fn too_many_changes() -> Self

👎Deprecated:

always use too_many_changes_with_limit to include the limit per RFC 8620 §9.6.1

RFC 8620 §5.6 — “tooManyChanges”

Always prefer too_many_changes_with_limit, which includes the server’s limit so the client knows the maximum maxChanges value to use on retry. RFC 8620 §9.6.1 requires limit to be present on the wire; this bare constructor produces a wire form that violates that requirement.

pub fn too_many_changes_with_limit(limit: u64) -> Self

Returns a tooManyChanges error with the server’s limit included.

Per RFC 8620 §9.6.1, the limit field MUST be present so the client knows the maximum maxChanges value to use on retry.

pub fn not_json() -> Self

RFC 8620 §3.6.1 — “notJSON” (request-level error)

The request body was not valid JSON or did not have application/json content type.

pub fn not_request() -> Self

RFC 8620 §3.6.1 — “notRequest” (request-level error)

The request parsed as JSON but did not match the JMAP Request object shape.

pub fn limit(limit_name: impl Into<String>) -> Self

RFC 8620 §3.6.1 — “limit” (request-level error)

The request was rejected because it would exceed a capability limit such as maxCallsInRequest or maxSizeRequest.

limit_name is the name of the exceeded limit (e.g. "maxCallsInRequest"). The HTTP layer MUST forward this name as the "limit" property in the RFC 7807 Problem Details response body. The name is stored in description for that purpose.

Invariant: always construct limit errors with this function, never by setting error_type = "limit" and description manually. The HTTP response layer (jmap-server::RequestError) reads description to populate the RFC-required "limit" field; a missing description produces an invalid response.

pub fn unknown_capability() -> Self

👎Deprecated:

always use unknown_capability_with_detail to include the URI in the error

RFC 8620 §3.6.1 — “unknownCapability” (request-level error)

The request used a capability URI not recognized by this server.

Always prefer unknown_capability_with_detail, which includes the failing URI so clients can act on it.

pub fn unknown_capability_with_detail(uri: impl Into<String>) -> Self

“unknownCapability” with the failing URI surfaced to the client.

Always use this instead of unknown_capability().

The URI is stored in description. The HTTP layer (jmap-server::RequestError) reads description to populate the "detail" field in the RFC 7807 problem-details response body — the same mechanism used by limit() for its limit-name payload.

Invariant: always construct unknownCapability errors that carry a URI with this function, never by setting description manually. A missing or incorrect description means the client never learns which capability it requested that the server does not support.

pub fn custom(error_type: impl Into<String>) -> Self

Create a JmapError with a custom or extension error type string.

Use this when propagating a server error whose type value is not one of the RFC 8620 standard types, or in tests that need to construct an arbitrary JmapError value.

Trait Implementations

impl Clone for JmapError

fn clone(&self) -> JmapError

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for JmapError

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for JmapError

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Display for JmapError

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

Formats the value using the given formatter.

impl Eq for JmapError

impl Error for JmapError

fn source(&self) -> Option<&(dyn Error + 'static)>

Returns the lower-level source of this error, if any.

fn description(&self) -> &str

👎Deprecated since 1.42.0:

use the Display impl or to_string()

fn cause(&self) -> Option<&dyn Error>

👎Deprecated since 1.33.0:

replaced by Error::source, which can support downcasting

fn provide<'a>(&'a self, request: &mut Request<'a>)

🔬This is a nightly-only experimental API. (error_generic_member_access)

Provides type-based access to context intended for error reports.

impl PartialEq for JmapError

fn eq(&self, other: &JmapError) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for JmapError

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for JmapError