ef0c1c2808The revision has no way for a server to put a request on a response stream, so a handler that needs input from the user says so in its result instead: a handler returning InputRequiredResult comes back as resultType: "input_required" with the asks and an opaque requestState, and the client retries the same request carrying inputResponses. RequestContext::getInputContext() is what the handler reads them through. RequestStateCodec signs and time-bounds the state, so a tampered or expired one is refused rather than trusted - the state travels through the client, which is not a place to keep something the server later believes.
47 lines
2.4 KiB
YAML
47 lines
2.4 KiB
YAML
# Expected conformance failures for spec revision 2026-07-28.
|
|
#
|
|
# Separate from conformance-baseline.yml because the two revisions exercise
|
|
# different lifecycles against different endpoints: the dated baseline covers
|
|
# the handshake era served at /, this one covers the modern (SEP-2575) era
|
|
# served at /stateless.
|
|
#
|
|
# Entries are per-check (scenario:check-id) rather than whole scenarios, so a
|
|
# scenario that is mostly conformant keeps reporting the parts that work and a
|
|
# new regression inside it still fails the run.
|
|
#
|
|
# Run with:
|
|
# make conformance-draft-server
|
|
|
|
server:
|
|
# --- Progress notifications on a response stream ---------------------------
|
|
# The one place the modern lifecycle is behind the handshake one, and a real
|
|
# gap rather than a fixture difference: this scenario passes at / and fails
|
|
# at /stateless. A tools/call answer is a single JSON response here, so
|
|
# notifications a handler emits mid-call have nowhere to go. Closing it means
|
|
# answering tools/call over a stream — the same seam MRTR's IncompleteResult
|
|
# chunks will need — rather than anything specific to progress.
|
|
- tools-call-with-progress:tools-call-with-progress
|
|
|
|
# --- SHOULD-level warnings -------------------------------------------------
|
|
# These report WARNING rather than FAILURE (the severity follows the spec
|
|
# keyword), so the run summary counts them as passed — but the baseline
|
|
# evaluator still wants them declared, and declaring them is right: each is a
|
|
# SHOULD the SDK does not yet honour. Both concern the resources/read
|
|
# not-found shape: SEP-2164 moved it to -32602 with the uri in error.data,
|
|
# and the SDK still answers with the older -32002 and no data.
|
|
- sep-2164-resource-not-found:sep-2164-data-uri
|
|
- sep-2164-resource-not-found:sep-2164-error-code
|
|
|
|
# --- Pre-existing, not lifecycle-specific ----------------------------------
|
|
# Neither is caused by (or fixable in) the modern lifecycle; both reproduce
|
|
# on the handshake endpoint. Listed so the draft run is honest.
|
|
#
|
|
# json-schema-2020-12 wants a `json_schema_2020_12_tool` fixture that neither
|
|
# conformance server defines, so the scenario has nothing to exercise.
|
|
# resources-templates-read is the single remaining wire-schema failure: the
|
|
# fixture emits a resource-template URI in a shape the schema rejects, on
|
|
# both revisions.
|
|
- json-schema-2020-12:json-schema-2020-12-tool-found
|
|
- resources-templates-read:wire-schema-valid
|
|
|
|
client: []
|