Wymcp.
View Source
Message classification: tags
every inbound body with its JSON-RPC message kind —
conn.assigns[:wymcp_message_type], one of :request,
:unidentified_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 — the discriminating keys and, for a body with
both a binary "method" and an "id", whether that id is a
request id, in clause order:
| Body signals | Kind | Downstream |
|---|---|---|
"method" (binary) + "id" that is a request id | :request | dispatched; the one kind whose id a rejection echoes (Wymcp.Response.rejection_id/1) |
"method" (binary) + any other "id" | :unidentified_request | rejected by Wymcp.Plugs.Validate ahead of the schema check; its id is never echoed — no answer could carry it back usably |
"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 in
everything but the id — a recognisably malformed request, such as one
naming the wrong "jsonrpc", 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.
The id is the exception because it is the value every answer carries
back: deciding it here, once, means no answer anywhere in the pipeline
echoes an id outside the rule — Wymcp.Plugs.Auth's 401 included, which
runs ahead of validation.