This is false. The example above shows that the request for the schema was a valid, attestable query both before and after the upgrade but produces a different response (one response with the new feature listed in the schema and one response without). Even if we did not have a case today which was “more breaking” than the provided example, it would be a desirable feature of our versioning capabilities to be able to make such breaking changes as needed.
I would also like for us to have the mindset that for pure functions errors are not “special”. Non-special errors simplifies thinking and leads to better outcomes. It is desirable to have attested errors. There’s been a lot of effort and discussion around this and it ties in to many conversations from security to ISA / QoS. Removing attestations from errors is a non-starter.
The complication arises not because of GraphQL but because of the sensitivity of attestations to minor changes in the output due to the use of hash functions. (Verifiable queries might not improve the situation). So it may be useful to step back and ask not what is a breaking change for GraphQL but what is a breaking change for attestations. Then the answer becomes “almost everything”. This would be true regardless of whether or not GraphQL was used.
To add clarity and to emphasize that this is a breaking change for attestations only, I think we should rename “protocol version” to “query attestation version” both conversationally and in the contracts. If you think of this as the “query attestation version” and not the “protocol version” you will come up with different answers to some of your questions and concerns. The point I was trying to make earlier by saying that attestations “go away” for actual protocol version upgrades (eg: a feature moving from attestations to verifiable queries) is that this EIP-712 domain hash is only used for attestations and never used for verifiable queries or anything else in the protocol. So the scope of affected areas for this version bump is much smaller than the name implies.
A minor note: the PoI is not signed and the query attestation version is not relevant to PoI.
A council vote is required by the GIP regardless of the concern around attestations. A feature moving from “Experimental” to “Query Dispute Arbitration” requires a vote - and that is what block: { number_gte } is.
In the proposal that the client specifies the version with the query, upgrading in lock-step is not necessary for either the client or the Indexer. The Indexer can answer queries for ranges of protocol versions with backward compatible code all the way to version 0 and there is no fundamental reason to deprecate N-1 versions (possibly ever). That’s a major advantage of client specified versions.