Allow composition errors to be ignored ... or?

[dchambers]

Description

We can use --query-count-threshold, --query-percentage-threshold, and --validation-period as a means to completely ignore operation errors, but there does not seem to be something like a --ignore-composition-errors switch to do the same for composition errors.

Motivation

My motivation for wanting this is that I have a build step (in our schema governance repo) that's only interested in operation errors. It's also worth pointing out that I wouldn't be trying to do this at all if there was a way to provide schemas for multiple subgraphs at the same time, for example:

rover subgraph check <graph-ref> --schema <schema1> --name <subgraph1> --schema <schema2> --name <subgraph2>

since then there wouldn't be any composition errors -- the governance PRs sometimes involve updates to multiple schemas at the same time, and I'd like to be able to confirm that those change will compose on dev and won't be breaking on prod.

FYI: I'm working around this single-subgraph check limitation by using rover subgraph fetch to download all subgraphs except those that have been changed within the PR, then using rover supergraph compose to verify composition. The thing I lose by doing this are the operation checks, which I can get back with rover subgraph check, but only for PRs that change just a single subgraph.

Thoughts?

[dchambers]

I've just found an even more compelling reason for wanting this feature. Although subgraph teams are already recommended to setup Apollo checks within their CI pipelines, this is not possible to enforce. We'd therefore like to be able to centrally prevent the publishing of schemas that break operation errors to eliminate this aspect of operational risk.

[dchambers]

Yet an even more compelling reason for this feature is where a composition error starts to occur on staging or prod, where CI checks are required, and therefore blocking PRs that would fix that composition error.