Subscription in Apollo 4: GraphQL errors never trigger error callback with `client.subscribe()` - intended?

[ItaiYosephi]

Description

After upgrading to Apollo Client 4, GraphQL errors in subscription responses never trigger the error callback. They always arrive in the next callback via result.error, regardless of errorPolicy.

The only difference between error policies:

• errorPolicy: 'none' → data becomes undefined, errors in result.error
• errorPolicy: 'all' → data preserved, errors in result.error

Server response payload

{
  "payload": {
    "data": {
      "mySubscription": { "id": "123", "status": "active" }
    },
    "errors": [
      {
        "message": "Resource not found",
        "path": ["mySubscription", "relatedEntity"],
        "extensions": { "code": "NOT_FOUND" }
      }
    ]
  }
}

Client code

client.subscribe({ query: MySubscription }).subscribe({
  next: (result) => {
    // GraphQL errors always arrive here in result.error
    // With 'none': result.data is undefined
    // With 'all': result.data is preserved
  },
  error: (error) => {
    // Never called (for GraphQL errors at least....)
  },
});

Questions:

1. Is this the intended behavior for subscriptions in Apollo Client 4?
2. What errors are expected to trigger the error callback?
3. Should errorPolicy: 'none' route GraphQL errors to the error callback (as it seemed to in v3)?

Environment

• @apollo/client: 4.x
• Multipart HTTP subscriptions

---

[phryneas]

Yes, that is intended - we changed that for all Apollo Client-emitted Observable instances.

Most of those Observables can emit errors, but then e.g. keep watching the cache and recover from the error that way, emitting new values. So calling error on our end would always tear down the subscription, even if there might be valid emitted values in the future.

Similarly, for subscriptions, a server might send valid data after an error (see this test), at which point an error should not close the subscription.

That said, a non-recoverable error like a network error will still cause the subscription to be "completed" after emitting the error via next: see this test.

It wouldn't make sense if we emitted some errors via next and others via error, so all errors are emitted via next, and error will never be called.

PS: I believe we haven't specifically pointed this out for subscriptions, but the general change of direction was mentioned in the style guide here

[ItaiYosephi]

@phryneas , Thanks for your response! worth mentioning this behavior in the docs about error handling.

I also noticed that when a subscription has error, retryLink is causing is throwing AbortError: BodyStreamBuffer was aborted, and the Subscription operation observable never completes and n ever errors.
Any idea why? it's working fine in Apollo 3. I wonder if retryLink should not be used for subscriptions

[phryneas]

@copilot open a PR with a reproduction for the AbortError: BodyStreamBuffer mentioned in #13125 (comment)

(huh... why doesn't that work? ah well let's see where #13126 leads)