Subgraph GraphQL Errors are being silently ignored

[iameli]

Describe the bug (required)
Errors returned from the subgraph server aren't bubbling up to the components for some reason. When GraphQL sends us an errors field back it gets lost somewhere in the Apollo internals. We can see them in the Apollo client here if we log out value.errors:

but the client seems to completely lose track of them after that point. I can call observer.error() with them but that just makes it log out a "network error" and still nothing makes it to a component.

Expected behavior (required)
Per the Apollo docs, I'd expect to see a props.error (or maybe props.data.error?) available to, for example, this enhancer function in the Explorer.

To Reproduce (required)
Steps to reproduce the behavior:

1. Start up explorer with the environment variable REACT_APP_LIVEPEER_SUBGRAPH set to https://api.thegraph.com/subgraphs/name/iameli/livepeerdev
2. Navigate to the transcoders page
3. It won't load, nor will it provide an error to the component

[adamsoffer]

@iameli Interesting. Yeah, those errors should definitely be made available to components. Regarding those errors, as you're probably aware the subgraph doesn't yet index all the delegator fields the Explorer requires. For example, we can't yet index fees, pendingFees, bondedAmount, and pendingStake because the claimEarnings function doesn't emit an event (indexing function calls with no event emitters is on The Graph's near term roadmap). What we could do in the meantime is extend the Delegator type with those missing fields using Apollo schema stitching and the Livepeer SDK. There's a pretty good write up on how this can be done here.

[iameli]

Awesome! Yeah, I briefly looked through the stitching pattern, seems reasonable.

I'm wondering if this problem is maybe related to the way we compose several Apollo enhancers to set up the final props for the transcoder component and such — maybe an error-free Apollo context is clobbering the errors from this one. So far as I can tell we're doing the correct thing on the ApolloLink level by calling observer.next with the errors array.

[adamsoffer]

Not 100% sure, but there's an open apollographql issue that implies the errors are being swallowed because we're using schema stitching.

[iameli]

Hmm possibly both of our suspicions — when I comment everything except for connectTranscodersQuery here I get errors in the component.

But if I uncomment them that error flashes up for a second and vanishes. Still diagnosing.

[iameli]

As suggested on this unrelated bug, notifyOnNetworkStatusChange: true seems to improve the issue. It still gets stuck in "loading" with no errors for a while... but then it fixes itself and the errors stay visible.

Unsatisfying. No idea what's going on... but that unblocks my immediate concern I suppose.