Wymcp.
View Source
Message classification: tags
every inbound body with its JSON-RPC message kind —
conn.assigns[:wymcp_message_type], one of :request, :notification,
or :unknown — so the rest of the pipeline branches on the kind instead
of re-reading body fields: 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 |
| none of the above | :unknown | rejected by Wymcp.Plugs.Validate once the wire checks pass; its id is never echoed — on such a body, request and response are indistinguishable by construction |
A JSON-RPC response — an id beside a result or an error — is
:unknown: the spec forbids a client to send one, since a server
initiates no request of its own; a client's answers to a mid-call
question ride inside the retried tools/call under
MRTR instead.
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.