[Tests] Fix resources-templates-read to return a resolved URI (#460)

The fixture returned the literal template pattern test://template/{id}/data
instead of substituting id, failing the wire-schema uri format check. Also
switches the json-schema-2020-12 baseline entry to a bare scenario name: the
latest (0.1.x) conformance CLI doesn't parse scenario:check-id syntax, only
alpha (0.2.x) does, and the two need to agree since conformance-weekly runs
2025-11-25 against latest while pipeline.yaml pins alpha.

Verified locally against both dist-tags and both spec revisions.
This commit is contained in:
Christopher Hertel 2026-08-19 00:14:46 +02:00 • committed by GitHub
commit f6a995bc44
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 3 additions and 58 deletions

View file

@ -146,7 +146,7 @@ final class Elements
public function resourceTemplate(string $id): TextResourceContents
{
return new TextResourceContents(
uri: 'test://template/{id}/data',
uri: \sprintf('test://template/%s/data', $id),
mimeType: 'application/json',
text: json_encode([
'id' => $id,

View file

@ -1,32 +1,9 @@
# Expected conformance failures for spec revision 2025-11-25.
#
# Separate from conformance-baseline-2026-07-28.yml because the two revisions
# exercise different lifecycles against different endpoints: this file covers
# the handshake era served at /, the other 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-server
# make conformance-client
# Both pre-existing fixture bugs, not lifecycle-specific: json-schema-2020-12
# wants a `json_schema_2020_12_tool` fixture neither conformance server
# defines, and resources-templates-read emits a resource-template URI in a
# shape the schema rejects. Reproduce identically on the 2026-07-28 endpoint
# (see conformance-baseline-2026-07-28.yml).
server:
- json-schema-2020-12:json-schema-2020-12-tool-found
- resources-templates-read:wire-schema-valid
- json-schema-2020-12
client:
- elicitation-sep1034-client-defaults
- sse-retry
# The example client doesn't call add_numbers or echo the tool's inputSchema
# back, so these checks have nothing to exercise.
- tools_call:tool-add-numbers
- json-schema-2020-12-preservation:json-schema-2020-12-client-echo-completed
- auth/metadata-default
@ -50,4 +27,3 @@ client:
- auth/client-credentials-jwt
- auth/client-credentials-basic
- auth/cross-app-access-complete-flow

View file

@ -1,36 +1,6 @@
# Expected conformance failures for spec revision 2026-07-28.
#
# Separate from conformance-baseline-2025-11-25.yml because the two revisions
# exercise different lifecycles against different endpoints: the other file
# covers the handshake era served at /, this one 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
# make conformance-draft-client
server:
# --- 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
- json-schema-2020-12
# The client does not speak 2026-07-28 at all yet: it still opens with
# `initialize` regardless of revision, so it never reaches the stateless wire
# (no per-request `_meta`, no Mcp-Method/Mcp-Name headers, no client-side
# requestState) — and separately, the SDK ships no OAuth client, so every
# scenario driving an authorization flow has nothing to exercise.
client:
- request-metadata
- http-standard-headers
@ -41,7 +11,6 @@ client:
- tools_call:tool-add-numbers
- json-schema-2020-12-preservation:json-schema-2020-12-client-tool-found
- json-schema-2020-12-preservation:json-schema-2020-12-client-echo-completed
- auth/metadata-default
- auth/metadata-var1
- auth/metadata-var2