Wymcp. Plugs. Classify
(Wymcp v0.1.1)
View Source
Message classification (docs/glossary.md, message classification):
tags every inbound body with its JSON-RPC message kind —
conn.assigns[:wymcp_message_type], one of :request, :notification,
:response, or :unknown — so the rest of the pipeline branches on the
kind instead of re-reading body fields. Kin to era classification
(Wymcp.Plugs.Era): an early tag the rest of the pipeline reads.
The classification table — presence of the discriminating keys, in clause order:
| Body signals | Kind | Downstream |
|---|---|---|
"method" (binary) + "id" | :request | dispatched; the one kind whose id a rejection echoes (Wymcp.Response.rejection_id/1) |
"method" (binary), no "id" | :notification | dispatched; carries no id, so no answer can correlate to it — a rejection's envelope carries id: null |
"id" + "result" or "error", "method" missing or non-binary | :response | a client's answer to a server-initiated request — bypasses Wymcp.Plugs.Validate and is delivered by Wymcp.Plugs.Dispatch to the session that minted the id; misclassifying one misroutes sampling and elicitation answers |
| none of the above | :unknown | rejected by Wymcp.Plugs.Validate once the wire and session checks pass; its id is never echoed — on such a body, request and response are indistinguishable by construction |
The :request test is deliberately looser than schema validity — a
recognisably malformed request still classifies :request and keeps
its id through Wymcp.Plugs.Validate's rejection; why the id-echo
rule keys on this classification is Wymcp.Response.rejection_id/1's
story.