Tom Picton

> You'd then have to use fetchMore to trigger any network requests beyond the initial one I don't think that's true, otherwise requesting `first: 1` wouldn't resolve the issue described....

I wrote this as a repro of an honest-to-goodness Relay-conformant API where I see the same issue... but had ChatGPT write the dummy schema implementation for me. My bad, let...

Pushed a fix for the booleans serialized as strings. The cursor fields appear to be either `null` or a non-empty string on my end, though.

Yep, I think we're on the same page. The use case in our scenario is that our "zero people" request gathers some aggregate metadata over the connection, but we don't...

We're making use of `keyArgs` but it feels to me that the `@connection` directive would solve a lot of these problems e.g. the "fetch metadata over connection without loading edges"...

Unfortunately it seems that using `relayStylePagination` clobbers the `@connection` directive. [I've made a repro here](https://github.com/tpict/apollo-connection-first-0-repro/tree/tpict/directive-example) where I modified the mock schema to resolve no results if the `name` field isn't...

Thanks @jerelmiller for the quick response. If the extra context helps: the thing I'm struggling with is making a general-purpose error boundary that can present users with a "retry" button....

That's actually the solution I _thought_ would work, but I found that for Apollo client >= 3.11.3 &&

I've made a rough-and-ready demo @jerelmiller. Behavior is what I'm seeing in our application: the `useSuspenseQuery` call throws immediately without reaching out to the API. https://github.com/tpict/react-apollo-error-inconsistency It's on 3.11.4, but...

Hey @jerelmiller and sorry for the delay getting back to you. That makes total sense. The hack I have currently (custom link associating error instances to queries) seems to work...