Struct PairingCodeError 

#[non_exhaustive]
pub struct PairingCodeError {
    pub rejection: Option<PairCodeRejection>,
    pub backoff: Option<Duration>,
    pub error: String,
}

A phone-number pair-code flow failed, so no linking will come of it.

The counterpart to PairingCode on the failure path, and the only surface that reports it when pairing is driven by BotBuilder::with_pair_code — that request runs in a detached task, so nothing returns its error to the caller. Client::pair_with_code dispatches this in addition to returning Err, matching how the success path both returns the code and emits PairingCode.

Both of the flow’s server round trips report here, and the consumer’s move is the same either way — this code is finished, request another or fall back to the QR. The later one arrives after a code was already displayed and entered: the phone answered, but the server refused the key bundle that answer produced. Silence at that stage is not this event, because nothing was refused; it surfaces as PairingCodeRefresh once the timer runs out.

Fires for every failure, including local validation (a phone number that is too short never reaches the server): a consumer waiting on a code needs to learn that it is not coming, whatever the reason. rejection is what distinguishes the two — None means the request never got an answer from the server.

A claim the failed request itself took is released before this fires, so nothing is left holding the flow and pair_with_code can be called again.

Two failures do not arrive here, because for them a code may still be on its way and this event would say the opposite — a consumer acting on it would tear down a code that is about to arrive:

• CodeAlreadyOutstanding — refused precisely because an earlier code is still live, and the consumer already has it from the PairingCode that minted it. Retrying is futile until cancel_pair_code runs or the window closes.
• Cancelled — the caller withdrew this request, and a replacement may already own the slot. A superseded request can return this after its replacement started, so the event would be uncorrelated with the flow that is actually running.

Both follow from something the caller did, so neither is news, and a direct caller still gets the Err.

Whether to retry at all is the point of the fields: back off on PairCodeRejection::is_throttled, stop on PairCodeRejection::FeatureNotAvailable.

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.

rejection: Option<PairCodeRejection>

The server’s refusal, when it answered with one. None when the failure was local (validation, no connection) or the request went unanswered (timeout) — nothing was refused, so there is no status to report.

backoff: Option<Duration>

How long the server asked the client to wait, from the backoff attribute. Usually absent — WA Web does not read it on this path — but when present it is the server naming its own retry delay, which beats any interval the consumer would pick.

error: String

The failure rendered for logs. Do not branch on it; use rejection.

Implementations

impl PairingCodeError

pub fn builder() -> PairingCodeErrorBuilder

Create an instance of PairingCodeError using the builder syntax

Trait Implementations

impl Clone for PairingCodeError

fn clone(&self) -> PairingCodeError

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for PairingCodeError

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

Formats the value using the given formatter.

impl Serialize for PairingCodeError

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

where __S: Serializer,

Serialize this value into the given Serde serializer.