[updated] build_errors not showing as output of subgraph check

[y-nk]

Steps to reproduce

Running a rover subgraph check --format json ... command in local raises:

{
  data: {
    success: false,
    tasks: {
      lint: {},
      tasks: {}
    }
  }
}

But running the same command in (Github) CI (with same rover version) produces:

{
  data: {
    success: false,
  }
}

Expected result

The output should be the same

Actual result

The output is not the same

Environment

Local

Rover Info:
Version: 0.22.0
Install Location: $HOME/Library/Application Support/fnm/node-versions/v20.11.0/installation/lib/node_modules/@apollo/rover/node_modules/binary-install/node_modules/.bin/rover
OS: Mac OS 14.3.1 [64-bit]
Shell: /bin/zsh

CI

Rover Info:
Version: 0.22.0
Install Location: /opt/hostedtoolcache/node/20.11.0/x64/lib/node_modules/@apollo/rover/node_modules/binary-install/node_modules/.bin/rover
OS: Ubuntu 22.04 (jammy) [64-bit]
Shell: Unknown

[y-nk]

update:

this is a bug, but another kind.

after adding --log debug i could see the exact error. in my local, for unknown reason an internal query (SubgraphCheckWorkflowQuery) would return a different output from local to CI.

In local:

DEBUG rover_client::blocking::client: Request Body: {"variables":{"workflowId":"********","graphId":"********"},"query":"query SubgraphCheckWorkflowQuery($workflowId: ID!, $graphId: ID!) { ******** }","operationName":"SubgraphCheckWorkflowQuery"}
    at crates/rover-client/src/blocking/client.rs:89

DEBUG hyper::client::pool: pooling idle connection for ("https", api.apollographql.com)
    at /Users/distiller/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hyper-0.14.27/src/client/pool.rs:376

{"data":{"core_schema_modified":true,"success":false,"tasks":{********}},"error":{"code":"E043","message":"The changes in the schema you proposed caused operation checks to fail."},"json_version":"2"}

{"data":{"core_schema_modified":true,"success":false,"tasks":{********}}

In CI (partially redacted):

DEBUG rover_client::blocking::client: Request Body: {"variables":{"workflowId":"********","graphId":"********"},"query":"query SubgraphCheckWorkflowQuery($workflowId: ID!, $graphId: ID!) {\n  graph(id: $graphId) {\n    checkWorkflow(id: $workflowId) { ******** }","operationName":"SubgraphCheckWorkflowQuery"}
    at crates/rover-client/src/blocking/client.rs:89

DEBUG hyper::proto::h1::decode: incoming chunked header: 0x1 (1 bytes)
    at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hyper-0.14.27/src/proto/h1/decode.rs:298
{"data":{"success":false},"error":{"code":"E029","details":{"build_errors":[{"code":"INVALID_FIELD_SHARING","message":"Non-shareable field \"PageInfo.hasNextPage\" is resolved from multiple subgraphs: it is resolved from subgraphs \"********\" and \"********\" and defined as non-shareable in all of them","nodes":null,"type":"composition"},{"code":"INVALID_FIELD_SHARING","message":"Non-shareable field \"PageInfo.hasPreviousPage\" is resolved from multiple subgraphs: it is resolved from subgraphs \"********\" and \"********\" and defined as non-shareable in all of them","nodes":null,"type":"composition"},{"code":"INVALID_FIELD_SHARING","message":"Non-shareable field \"PageInfo.startCursor\" is resolved from multiple subgraphs: it is resolved from subgraphs \"********\" and \"********\" and defined as non-shareable in all of them","nodes":null,"type":"composition"},{"code":"INVALID_FIELD_SHARING","message":"Non-shareable field \"PageInfo.endCursor\" is resolved from multiple subgraphs: it is resolved from subgraphs \"********\" and \"********\" and defined as non-shareable in all of them","nodes":null,"type":"composition"}]},"message":"Encountered 4 build errors while trying to build subgraph \"custom-fields-api\" into supergraph \"********@********\"."},"json_version":"1"}

{"data":{"success":false}}

I do understand those are build errors and not lint/operation check errors. I still don't know why the exact same command produces 2 different output. maybe some caching locally? i've no clue.

As a feature request, it'd be nice that build_errors would spill to this command's output, so that we're not left in the dark or forced to add --log debug to know what's going on. the information is there, but sadly discarded while it could be printed.