ErrorExchange doesnt seem to be called

[atomkirk]

Describe the bug
ErrorExchange doesnt seem to be called

To Reproduce
When I print the error in this code:

    cancellable = NetworkClient.shared.query(Meeting.upcoming)
      .receive(on: RunLoop.main)
      .sink(
        receiveCompletion: { [weak self] completion in
          switch completion {
          case .finished:
            break
          case .failure(let error):
              print(error)
            self?.data = .error(error.localizedDescription)
          }
        },
        receiveValue: { [weak self] result in
          let meetings = result.data
          self?.data = .loaded(meetings)
        })

it prints:

graphql([GraphQL.GraphQLError(message: "You must have a valid auth token", locations: Optional([GraphQL.GraphQLError.Location(line: 2, column: 3)]), path: Optional([GraphQL.GraphQLError.PathLink.path("meetingsrootQueryType_1j20o8pjuatoy")]), extensions: nil)])

However, here is my network client code:

  static let shared: SwiftGraphQLClient.Client = SwiftGraphQLClient.Client(
    request: URLRequest(url: http),
    exchanges: [
      DebugExchange(),
      DedupExchange(),
      AuthExchange(
        header: "Authorization",
        getToken: {
          if let token = TokenManager.shared.token {
            return "Bearer \(token)"
          }

          return nil
        }),
      cache,
      FetchExchange(encoder: encoder),
      WebSocketExchange(client: socket),
      ErrorExchange(onError: { err, blah in
        print(err)
        print(blah)
      }),
    ]
  )

it appears ErrorExchange never gets called

Expected behavior
I'd like to clear my token when I get back an error that the token is no longer valid. Is there another way you'd recommend doing this?

[shaps80]

This could be a bug but I think I've witnessed something similar myself and found the error handling atm is complicated to do right because to the usage of Combine and how things are setup.

I have a whole new foundation coming soon that replaces Combine entirely with async/await and throwing methods which solves this entirely.

It also brings a lot of other benefits ofc. You can read more about that here if you like:

• Project Roadmap #185

---

I will check into this though and get back to you.

[atomkirk]

My use case is pretty simple right now so I'd be happy to try a pre-beta when its ready :) (would also benefit me because then it's probably less of a migration for me later?)

[atomkirk]

I think this project will become the most popular way to consume graphql on ios. This very much models https://github.com/dillonkearns/elm-graphql which I've used heavily and really really love. It's a much much better approach than writing string queries and running a generator that looks for them and writes types specific to those queries like virtually all js libs. Keep up the great work!

[shaps80]

@atomkirk well I might upset you then haha.
The approach I'm working on atm goes in a far more Swift based solution. It solves a lot of issues but also moves away from GraphQL language where it's a barrier to entry and migration will def be a larger effort.

I feel strongly its a better direction for a Swift version of this library, but given Mat clearly had different ideas it may not be appropriate.

Its possible that Mat and I decide its the wrong direction for this library in which case I'll be open sourcing as a separate effort (if the approach pays off).

But I'm hopeful that Mat and I can align on this because I agree, he's done an amazing job and having a defacto GraphQL library for Swift would be amazing.

If you review my Discussions or the Roadmap you can see that I really want to focus more on the developer experience and lowering barrier to entry to almost nothing.

In fact the approach I have in mind, has an almost flat line learning 'curve'. I struggle to call it a curve at all hahaha.

Anyway, let me know if this sounds backwards or scary to you – genuinely appreciate all input.

And once I've gotten some thoughts/input from Mat, I actually do plan on detailing the whole thing in a dedicated Discussion #194 that will cover everything and give everyone early overview of the intended design.

But again, this is first-and-foremost Mat's library so I need to get his input before I can say what direction we're going to take. My approach is radically different tbh.

One thing I can say almost for certain however, is that I've already rewritten the low level APIs (GraphQL package) to include a custom global actor/executor as well as full async/await and throwing methods support.

It brings modern features to the foundation, improves the developer experience ten fold and makes it way easier to maintain and understand what's going on.

The actor in particular provides end-to-end thread safety without the consumer doing anything and therefore brings a lot more predictability and reliability to the library as a whole.

The high level APIs need updating to make use of this, but I'm fairly certain this will happen over the next few months.

Thanks again!

[shaps80]

#194 @atomkirk if you're keen for an early look at the POC I've been exploring that discussion has a lot more detail now.

It's still very early stage and needs more fleshing out but you can get an idea of the direction and I'd appreciate any feedback you may have. 👍