Useful report - the conformance suite pinning to 2026-07-28 is doing its job. A few observations that might help triage the 7 failures:

The two clusters are different severity. Missing server/discover (Method not found) is a hard gap: the revision treats it as required, and any client negotiating 2026-07-28 will fail against the example server. The version-less tools/list rejection is a negotiation-semantics question: per the spec, a version-less request should resolve to the highest mutually supported revision and be served, not rejected.
The SDK client not yet implementing 2026-07-28 explains the official SDK interop passes, and it means the suite is ahead of the implementation. That does not make the failures cosmetic - third-party clients (the test tool itself) negotiate the newest revision and hit them. Worth treating the discover gap as the P0 and the rest as revision-support backlog.
A minimal server/discover implementation is small: advertise supported revisions (2025-11-25, 2026-07-28) and return the negotiated revision and capabilities; the example server can ship it before the SDK client catches up, which also gives the conformance suite a green target to compare against.
Version-negotiation logging would help: log the negotiated revision at handshake time, so a client that silently falls back to 2025-11-25 is visible instead of passing tests while negotiating an old revision.

At corpusiq.io we pin the negotiated revision in the handshake and log the negotiated value on every connect; version-negotiation failures are the first thing surfaced in support because they look like silent feature loss otherwise.

[removed by maintainer due to spam] #3372

Description

Activity

Ben-Home commented on Aug 24, 2026

maxisbey commented on Aug 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions