Is should be possible to retry a request from a HTTPInterceptor

[andykent]

Use case

Context: I am converting a bunch of legacy v1 interceptors over to v2. I've been enjoying it so far but have hit a slight snag.

In one specific case I am trying to migrate an interceptor that catches 401 errors, fetches new tokens and then retries them. I assumed this should be moved to a HTTPInterceptor as it is purely concerned with the HTTP layer and doesn't touch the GQL query.

The docs state:

When a RequestChain receives a thrown RequestChain.Retry error, it will restart from step 1 of the Request Chain Flow using the request provided by the error. This allows the request to be modified to correct errors that may be causing the failure prior to beginning again.

I assumed from this that I would be able to modify the URLRequest, throw RequestChain.Retry and have the whole chain retry. Unfortunately though RequestChain.Retry requires a GraphQLRequest not a URLRequest and don't think I have any access to the GraphQLRequest from within a HTTPInterceptor?

Is this an oversight in the API or is it that I am missing something obvious?

A simplified version of what I am trying to do is included below:

final class TokenAddingInterceptor: HTTPInterceptor {
  func intercept(request: URLRequest, next: @Sendable (URLRequest) async throws -> Apollo.HTTPResponse) async throws -> Apollo.HTTPResponse {
    let jwt = try await getToken()
    var newRequest = request
    newRequest.addValue("Bearer \(jwt.token)", forHTTPHeaderField: "Authorization")
    let response = try await next(newRequest)
    if response.response.statusCode == 401 {
      await refreshToken()
      throw RequestChain.Retry( ??? )
    }
    return response
  }
}

Describe the solution you'd like

I think either support should be added for retrying requests from HTTPInterceptor or the docs should be updated to make it clearer what parts of the RequestChain do and don't support retrying.

[AnthonyMDev]

Hi @andykent. Thanks for the issue. I agree that it would be nice to support retrying requests from the HTTPInterceptors, but we weren't able to come up with a good way to make that possible without breaking the separation of responsibilities of the GraphQLInterceptors and HTTPInterceptors, which was a primary goal of this project.

You need to provide a new GraphQLRequest when retrying and we don't want the HTTPInterceptor to have access to the GraphQLRequest (I can elaborate on that design decision if desired). This means you'll need to do the retry from a GraphQLInterceptor.

I'll update the documentation to make this clearer. Thank you for bringing it to our attention.

---

You could turn this interceptor into a GraphQLInterceptor pretty easily, but I agree that it feels like the right separation of concerns here is to make it an HTTPInterceptor.

To work around this in your specific case, I would have your TokenAddingInterceptor throw a custom error and create a GraphQLInterceptor that is responsible for error handling and retrying. It can then catch that specific error to trigger a retry.

I think that this actually enforces better design practices. As your application evolves, you may have other situation in which you would like to retry a request. This way, you have each of your interceptors throw specific errors with the necessary information and the error handling interceptor encapsulates all of the error handling logic for your RequestChain. You may even want to implement some logic that ensures you haven't already retried the request or reports these not-fatal errors to an error tracking analytics platform. All of that should be part of a separate error handling interceptor.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.