MultipartResponseParsingInterceptor.ParsingError.cannotParseResponse

[GRajin]

Summary

Hello, There seems to be an issue with parsing the response.

failure(Apollo.MultipartResponseParsingInterceptor.ParsingError.cannotParseResponse)

This happens when trying to use the generated queries during the fetching process.

What works
☑ The installation and setup works good.
☑ Codegen - Downloading schema works good
☑ Codegen - Generating swift code from queries works good

What doesn't work
☒ Failure occurs when implementing the generated queries using ApolloClient

To Note
The implementation perfectly works with the legacy version of the Apollo Client

Version

Tried in version 1.16.0, 1.16.1, 1.17.0, 1.18.0, 1.19.0 and it doesn't work

Steps to reproduce the behavior

These are the steps I implemented.

1. Created an iOS project in Xcode
2. Using SPM, installed Apollo package[latest version]
3. Setup Apollo CLI and generated configuration json file
4. Using introspection, downloaded the schema from the server in .graphqls format
5. Added queries for fetching data in .graphql format
6. Ran code generation to generate as SPM module
7. Added the module via Swift package manager and linked to the target.
8. Created a shared ApolloClient for running the query

class Network {
    
    static let shared = Network()
    
    private(set) lazy var apollo = ApolloClient(url: URL(string: "https://countries.trevorblades.com/graphql")!)
}

9. Error occurs while fetching the response from server

private func fetchContinents() {
    Network.shared.apollo.fetch(query: GetAllContinentsQuery()) { result in
        print(result)
    }
}

11. failure(Apollo.MultipartResponseParsingInterceptor.ParsingError.cannotParseResponse)

Logs

----- Failure -----
Error Type: ParsingError
Error Description: The response data could not be parsed.
Full Error Object: cannotParseResponse
NSError Domain: Apollo.MultipartResponseParsingInterceptor.ParsingError
NSError Code: 1
NSError UserInfo: [:]
Error handled in fetch completion. Stack trace at this point:
0   World.debug.dylib                   0x00000001058b5d60 $s5World24ContinentsViewControllerC05fetchB033_201A3815233999ABBEA1B7BAF218466ELLyyFys6ResultOy6Apollo13GraphQLResultVy0A9SchemaAPI06GetAllB5QueryC4DataVGs5Error_pGcfU_ + 5424
1   World.debug.dylib                   0x00000001058bd271 $s6Apollo0A6ClientC5fetch5query11cachePolicy17contextIdentifier0G05queue13resultHandlerAA11Cancellable_px_AA05CacheF0O10Foundation4UUIDVSgAA14RequestContext_pSgSo012OS_dispatch_I0Cys6ResultOyAA13GraphQLResultVy4DataQzGs5Error_pGcSgt0A3API0U7QLQueryRzlFyA2_cfU_ + 161
2   World.debug.dylib                   0x00000001059195c4 $s6Apollo23InterceptorRequestChainC16handleErrorAsync_7request8response10completionys0F0_p_AA11HTTPRequestCyxGAA12HTTPResponseCyxGSgys6ResultOyAA13GraphQLResultVy4DataQzGsAH_pGct0A3API0N11QLOperationRzlFyyYbcfU_ + 372
3   World.debug.dylib                   0x00000001058be1f8 $sIegh_IeyBh_TR + 40
4   libdispatch.dylib                   0x0000000104b93a6d _dispatch_call_block_and_release + 12
5   libdispatch.dylib                   0x0000000104b94df6 _dispatch_client_callout + 8
6   libdispatch.dylib                   0x0000000104ba4cad _dispatch_main_queue_drain + 1361
7   libdispatch.dylib                   0x0000000104ba474e _dispatch_main_queue_callback_4CF + 31
8   CoreFoundation                      0x00007ff80042f4b5 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
9   CoreFoundation                      0x00007ff800429c05 __CFRunLoopRun + 2515
10  CoreFoundation                      0x00007ff800428df1 CFRunLoopRunSpecific + 550
11  GraphicsServices                    0x00007ff811d420cb GSEventRunModal + 137
12  UIKitCore                           0x00007ff8064acf68 -[UIApplication _run] + 875
13  UIKitCore                           0x00007ff8064b1ea9 UIApplicationMain + 123
14  UIKitCore                           0x00007ff805418793 block_destroy_helper.22 + 9747
15  World.debug.dylib                   0x00000001058b3efb $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ + 123
16  World.debug.dylib                   0x00000001058b3e77 $s5World11AppDelegateC5$mainyyFZ + 39
17  World.debug.dylib                   0x00000001058b3f68 __debug_main_executable_dylib_entry_point + 24
18  dyld                                0x0000000104c38478 start_sim + 10
19  ???                                 0x000000010618e2cd 0x0 + 4397261517
-------------------------------

Anything else?

There is an issue tracker opened in the Developer Forums but no relevant comments or response is available
https://developer.apple.com/forums/thread/777939

[calvincestari]

Thanks for creating the issue @GRajin. It seems like Apollo iOS is expecting a multipart response and either not getting it in the format it expects or some other weirdness with the accept and content-type headers. I'll take a deeper look at it tomorrow and get back to you.

[GRajin]

Thanks @calvincestari for looking into this and for the quick update.

I see that the server I am requesting data from is sending me the response in "application/json" format.

To verify, I'll try testing against a server configured to provide the output in the multipart format that Apollo iOS might be expecting.

Will let you know more details after performing a test. Thanks!!

[calvincestari]

The multipart format is usually only returned for deferred queries. An ordinary query without @defer should always return application/json.

[GRajin]

Ok @calvincestari.

Checking the implementation, the query in action is an ordinary query and does not use @defer. So the server sending the response in application/json is actually the correct behavior according to your explanation.

This means the issue likely isn't the server's Content-Type itself, but perhaps how the client is processing this standard response or maybe another header interaction as you initially suspected.

Thanks for diving in and let me know your thoughts.

[calvincestari]

I've looked into this today and there's a few funky things going on:

1. The response content-type is not consistently application/json nor multipart/mixed. I don't know if Trevor is just using an old version of Apollo Server but I've noticed that sometimes it will return application/json in which case the response is parsed without error, and sometimes it will return multipart/mixed which then fails to parse correctly.
2. When the response content-type is multipart/mixed it does not contain the protocol specifier; this is required because the Apollo clients support both subscriptions and defer multipart responses. Without the protocol specifier the multipart parser does not know protocol specification parser to instantiate.

I considered a change to our multipart support - If there is no protocol specifier in the response content-type then attempt to pick a default based on whether the operation is a subscription or not. This might work but I'm unsure of this change as we approach supporting more than one version of a protocol specification. An example of this is the incremental delivery spec (for @defer and @stream) which is nearing completion to be merged into the spec. Once that's merged then Apollo iOS will need to support both versions for a while and it's unknown how we'll do that. Right now the expectation is clear; include a protocol specifier in the response content-type otherwise it will fail parsing.

Ultimately I don't believe we should make any change and this is more a server-side problem than something we should 'fix' in Apollo iOS.

tl;dr - for multipart responses to be correctly parsed the response content-type must include a protocol specifier and the server being used at https://countries.trevorblades.com/graphql does not do that.

[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.

[GRajin]

Thanks for the clear explanation. I'll report this server issue to the server mainteners. Perhaps a more informative error message in the client for missing protocol specifiers could help others diagnose similar problems in the future.

[calvincestari]

@GRajin - I've put up PR apollographql/apollo-ios-dev#628 which will provide some additional context for why a multipart response might be failing. Should help in the future if anyone else encounters this type of error.

[GRajin]

Thanks @calvincestari!! This would provide more information to the developers using the client!!