Apollo-android: corrupted response reader, expected non null value for __typename

[vvbogdanov87]

Generated code contains non optional field __typename

  public static class Meta {
    static final ResponseField[] $responseFields = {
      ResponseField.forString("__typename", "__typename", null, false, Collections.<ResponseField.Condition>emptyList()),
      ....

The call to a server fails on

  private fun checkValue(field: ResponseField, value: Any?) {
    check(field.optional || value != null) {
      "corrupted response reader, expected non null value for ${field.fieldName}"
    }
  }

The problem is that a response from the server doesn't contain __typename fields(I call stored graphql operation.). I couldn't find Apollo plugin option to disable the generation of __typename fields.
This is a request sent by apollo generated code:

{
  "operationName": "myOperation",
  "variables": {
    "var1": "123",
    "var2": "456"
  },
  "query": "query myOperation($var1: ID!, $var2: ID!) { getDeal(var1: $var1, var2: $var2) { __typename appliedCount ...}"
}

myOperation is a stored operation. Is it possible not to include the redundant query parameter which basically duplicates the stored query with __typename included? If I understand it right, the server simply ignores query field and executes stored operation by name, and returns a response without __typename. nodejs client has an option to disable __typename fields. Is it possible for java?

[martinbonnin]

Hi 👋 . Can you elaborate on what a stored operation is?
__typename is mandatory in the GraphQL spec so I would expect any compliant server to return it.

[vvbogdanov87]

Sorry for the wrong term used. I meant Persisted queries.
I will check with the server owner why __typename is not included in the response. I'll close the issue or update it as soon as I get an answer.

[martinbonnin]

Ahh got it, thanks! That shouldn't change the actual response json indeed. Let me know what your backend folks say.

[vvbogdanov87]

@martinbonnin I haven't received an answer from the service owner yet. But looks like this is what they use https://graphql-ruby.org/operation_store/overview.html Basically it is not an Automatic persisted queries. The query is already stored on the server side. And the query is triggered by operationName, not by sha. Is this workflow supported by Apollo?
I have access to schema.sdl and operation schemas. I want to generate Java classes and a client to trigger the queries.

[martinbonnin]

Generally speaking, how the query is executed on the server shouldn't matter to Apollo Android. The server can cache based on the operationName or any other logic and that should work fine. What's important though is that:

1. Whenever the query content changes, operationName changes to make sure the server doesn't lookup a stale query.
2. __typename is correctly resolved.

In that specific case, I suspect 1. is the reason why the server doesn't send __typename back. Could it be that the server cached the query without __typename? Maybe during experimentation in GraphiQL? Apollo Android adds __typename to queries during codegen so if you ran this manually before codegen it wouldn't have __typename.

Can you try changing the operationName to force a refresh on the server? Does that help?

[vvbogdanov87]

I tried, it simply responds with 404

[martinbonnin]

Ok, that was worth a try :). There has to be some way to "register" an operation with your backend. I suspect in this case the query was registered without __typename. How would you typically add a new operation?

[vvbogdanov87]

Using web UI which saves queries on the server side.
From the request and the response I caught, all is needed to enable this workflow is to have addTypename option in compiler parameters and have an option to disable query field in the request.

[martinbonnin]

Using web UI which saves queries on the server side.

Got it 👍 . Can you try registering the query with a new name and including __typename there? Or have you tried that already?

From the request and the response I caught, all is needed to enable this workflow is to have addTypename option in compiler parameters and have an option to disable query field in the request.

That's not something I am super keen on doing as that will add one more option to the compiler and is a potential footgun since __typename is definitely needed as soon as fragments/polymorphism is required.

In the long run, I think what we want is to prevent __typename to be added for simple monomorphic cases like yours (see https://github.com/apollographql/apollo-android/issues/1458 for some discussion about this). But that is pretty deep in the compiler so it'll require some time.

All in all, I'd be very surprised if your backend doesn't support __typename. If it doesn't, fixing this server side is certainly a better fix moving forward than adding an option to the compiler.

[vvbogdanov87]

@martinbonnin It started to work after I manually added __typename fields to the query. Thank you so much! I'm closing the issue.

[martinbonnin]

Glad to hear that, Thanks for the update!