PARSE · VALIDATE · CORRELATE
Protocol errors: classify the failing layer
Edit a real request document. Follow validation, decoded payloads, a local handler and response-id matching.
Editable request
Response received by the client
Local receiver effects
Your experiment
Compare malformed JSON, a wrong protocol version, an unknown method and invalid parts. They fail at different gates and produce different JSON-RPC error codes. Inject a handler failure only after the request validates.
Use Play for a full minute at 1×, Pause to inspect a gate, or Next gate for manual review. The timeline and speed control operate on this exact validation trace. Editing an input resets the inspection without autoplay.
Validated part inspector
Version-pinned teaching subset: JSON-RPC 2.0 and the A2A v0.3.0 message/part shape. This is not a complete A2A SDK or a conformance validator. Only message/send is dispatched; batches, streaming, tasks, authentication and extensions are not implemented. The notification example teaches the generic JSON-RPC no-response rule, not a supported A2A call shape. Unknown fields are not a full-schema validation. File bytes use canonical padded Base64; URI references use a strict reserved example host and are never fetched. MIME labels are not content-sniffed. The handler creates only an in-memory teaching receipt. Sixty seconds is inspection time, not measured latency. JSON-RPC specification · Pinned A2A message reference · Official AICassindra articles.
Classify by the first failing boundary
Compare malformed JSON (-32700), wrong RPC version (-32600), unknown method (-32601), invalid part (-32602) and an injected handler fault (-32603). For each case record the earliest failed gate and which later stages did not run. A malformed document never reaches the application handler, so retrying identical bytes cannot fix its syntax. An internal error does not by itself prove a retry is safe either: this lesson has no durable effects or deduplication ledger. Classification is evidence for a recovery decision, not an automatic retry policy.
Edit an actual request document
Fixture loads a complete JSON example into the request editor. Selecting another fixture replaces your edits. The editor then becomes the source of truth: parsing, envelope validation, method dispatch and part validation all examine its current text. Keep the JSON-RPC request id separate from the nested messageId. Response correlation checks the former and preserves its type; neither identifier is a security credential or an implemented idempotency key in this lesson.
Apply a local validation policy
Per-part byte limit counts UTF-8 text, serialized JSON-object data, or decoded Base64 file bytes. It is not a limit on total request size or MIME content validation. Allow URI references permits only the fixture reserved HTTPS host and never fetches the linked content, whose size is consequently unknown. Mismatch response id corrupts correlation after handling; Inject server fault fails the local handler before a receipt is created. These toggles isolate different failure boundaries rather than simulating remote infrastructure.
Follow the earliest failed gate
Play presents the validation trace over a minute; Pause, Next gate, Restart, Speed and the timeline provide controlled inspection. An input edit resets the inspection. If a gate fails, later dispatch or handler stages are not run, but an error response can still be inspected. A successful local handler with a mismatched response id is not accepted by the client. Removing the top-level id illustrates a generic JSON-RPC notification without a response; it must not be treated as confirmed success or a fully supported A2A notification contract.