Module context 

What a handler is given, and the gate in front of it.

The rule this module exists to enforce

A feature-specific call consults the session’s negotiated FeatureProfile before anything is written. Not after, and not “write and let the peer cope” — before. A server that emits elicitation/create to a 2025-03-26 peer has told it something the protocol does not allow, and no error afterwards repairs that.

The testable form of that rule is GatedError::wrote_nothing: every refusal in this module either wrote nothing at all, or is explicitly marked as the one case that got far enough to write a request and then failed on the answer. The two halves are not the same and the type says so.

Why there are two types and not one

PeerSession is everything about the connection: the revision it settled on, the profile that fell out of that, and the two ports a handler needs to talk back. RequestContext is everything about the request being served, and holds a reference to a session.

The split is not tidiness. A profile and a transport are fixed when the connection negotiates and shared by every request on it; a request id, a cancellation token and a progress token differ on each. Collapsing them produces a constructor with eight parameters, five of which every caller has to invent for every request, and nothing stops a caller from taking them from the wrong request.

Structs

ExchangeError

Why a server-initiated request could not complete.

PeerSession

The negotiated connection a handler is serving.

RequestContext

Everything a handler is allowed to know about the call it is serving.

Traits

CallbackExchange

A round trip to the peer that a server-initiated request needs.

DynExchange

The boxed spelling of CallbackExchange, for a caller holding a transport of unknown concrete type.

Type Aliases

StateMap

The type-keyed state a Server carries into every request.