apollo-client: Unsure how to resolve `Missing field while writing result` error when using subscriptions

It’s been 8 monts and no one that works on apollo has replied? This also happens if mutations have missing fields. Just set them to null they are marked as optionel in the schema

Also getting the error using useQuery and MockedProvider

"@apollo/client": "^3.4.13"

How has nobody from Apollo commented on this post. Am I missing something?

@alessbell adding every field does solve the issue, but it would be super nice to be able to suppress that warning in tests so nullable fields we don’t care about for a test don’t need to be specified

Also getting this error now (after upgrading) while executing cache.writeQuery (but the cache seems to be properly updated). I’m not using subscriptions.

This error only seemed to appear for us when the data returned from the subscription was formatted in a way that Apollo doesn’t expect.

Example for an onAccountUpdated subscription:

data {
  id: 1,
  name: 'Kim'
}

This is the way some implementations like apollo-server-lambda return subscription data be default, but it’s incorrect, because of two reasons:

1. It’s missing the accountUpdated property wrapper
2. It’s missing the __typename property

We had to manually transform the data returned to subscriptions like this:

data: {
  accountUpdated: {
    __typename: 'Account',
    id: 1,
    name: 'Kim'
  }
}

The underlying issue (for us) is that apollo-server-lambda takes care of subscriptions through a different hander and is not aware of the normal “graph ways” of handling subscriptions and publishes, so the onus is on you to make sure the data is formatted in a “graph way”. It’s not great, but it seems to work.

Hope it helps other as well!

Hi everyone! I faced this issue a few weeks ago. In my case, the error was produced by a missing property in a mocked object used by a test. E.g.:

Error:

console.error
    Missing field 'name' while writing result {
      "id": "1",
      "colorHex": "white"
    }

Mocked object:

export const mockedObject: ObjectType = { ...otherProps, category: { colorHex: '#745EA8', id: '11', }, };

In this example, the ‘name’ property was missing in the mock used by the test, which has a type of:

interface Category {
  id: string;
  name: string;
  colorHex: string;
}

Solution: Make the property optional, or add a mocked value for the mocked object

I too am seeing this error surface after upgrading this morning…

Original versions.

    "@apollo/client": "^3.2.1",
    "@vue/apollo-composable": "^4.0.0-alpha.14",

Upgraded versions.

    "@apollo/client": "^3.4.13",
    "@vue/apollo-composable": "^4.0.0-alpha.15",

Hello. I’m getting this error when mocking query results. Here’s a CodeSandbox example: https://codesandbox.io/s/apollo-client-missing-field-error-srr15m

I had this error appear using MockedProvider / storybook-addon-apollo-client while mocking a specific query. It was complaining about Missing field icon.... In my case the mocked data being returned was in the wrong format:

Query:

export default gql`
  query GetIconQuery($iconId: String!) {
    icon(iconId: $iconId) {
      url
    }
  }
`;

Mocked data that was erroring:

{
   request: {
     query: GetIconQuery,
      variables: {
        iconId: icon.id,
      },
    },
    result: {
     data: {
       url: `icon.svg`,
     },
   },
}

The fix is to change result.data.url with result.data.icon.url because that’s the name of the query

{
   request: {
     query: GetIconQuery,
      variables: {
        iconId: icon.id,
      },
    },
    result: {
     data: {
       icon: {
         url: `icon.svg`,
       }
     },
   },
}

I’m still facing this issue with "@apollo/client": "3.7.0", using useQuery with relay style pagination. It’s a bit scary how an undefined value can break the cache and the pagination.

Given these two types

type MainSkills =  {
  hard?: string;
  soft?: string;
}

type User = {
  id
  name
  skills?: MainSkills
}

I use two fragments for the type User

fragment UserBasicData {
  id
  name
}

fragment UserFullData {
  id
  name
  skills {
    hard
    soft
  }
}

The errors appears when the data from the fragment UserBasicData is already stored in the cache and the data is refreshed with the data from UserFullData.

  updateQuery: (prev, { subscriptionData }) => {
        if (!subscriptionData.data) return prev;

        const newFeedItem = subscriptionData.data.sortedMessageSubscription;

        const newMessagesCached = {
          sortedMessages: prev.sortedMessages.concat(newFeedItem),
        };

        return Object.assign({}, prev, newMessagesCached);
      },

I solved mine by changing the code as above… where sortedMessages is the name of the field saved in the cache I really hope this helps someone

In our case solution was straightforward. When response fields were empty backend sent undefined instead of null due to misconfiguration. That lead to an issue with Apollo cache and missing fields error.

Not sure if it’s the best solution but this eliminated the error:

error is: ExceptionsManager.js:184 Missing field 'chat_channel' while writing result {}

updateQuery: (prev, { subscriptionData }) => {
        if (Object.keys(prev || {}).length === 0) {
          // there's nothing in cache, return empty array otherwise crash!
          return { chat_channel: [] }; <---------- instead of return prev;
        }

Maybe it helps someone facing that in tests:

It happened with me because a mocked resolver had an exception inside. In my case, I was accessing a property from the first item of an array inside the resolver and the array was empty. The error in the resolver didn’t show up, but I had that message from Apollo. When I added a validation for the item existence, the error went away.

Getting the same issue with apollo-client 3.5.0-beta.4.

Here is the relevant line in the source code, for those wondering: https://github.com/apollographql/apollo-client/blob/212b1e686359a3489b48d7e5d38a256312f81fde/src/cache/inmemory/writeToStore.ts#L327

Not really sure what I’m supposed to do to resolve the issue. (I know one way to solve it is to make sure the server returns a value for every field that Apollo is aware of; however I don’t want to have to do that, because the field is already marked as optional in the GraphQL defined on the server, so I want Apollo to be compatible with that without needing server-side workarounds)

EDIT: Found a temporary fix:

apolloClient = new ApolloClient({
	[...]
	cache: new InMemoryCache({
		typePolicies: {
			// temp fix
			MyClass: {
				fields: {
					missingField1(rawVal: boolean, {args}) { return rawVal ?? null; },
					missingField2(rawVal: string, {args}) { return rawVal ?? null; },
				},
			},
		},
	}),
});

EDIT2: Nevermind, that seems not to have fixed it – at least not reliably.

@AndreiRailean I had exactly the same issue but I didn’t have to fiddle around with graphql-ruby internals.

When I left the default subscribe method in one of my subscriptions I was getting the error described in this thread (because of data = {}) but then I tried to just override the subscribe to return nil and apparently that worked.

class MySubscription < BaseSubscription
  argument :whatever_argument, String, required: true

  def subscribe(whatever_argument:)
    nil
  end
end

This is now sending data = null in the cable connection.

Hope that helps people using graphql-ruby.

We faced a similar issue and upon close investigation, we ended up blaming it on ActionCable and how graphql-ruby gem works with it. The main issue is that upon initial subscription, it returns data={} because that’s how empty result gets serialised by .to_h call in ruby, i.e. it when result.data=nil, and the code runs result.to_h, you end up with result: data: {}.

This appears to have been a deliberate change introduced to better support Relay in 2019 in https://github.com/rmosolgo/graphql-ruby/pull/2536

https://github.com/rmosolgo/graphql-ruby/pull/2536/files#diff-a1ea5af1a78917fa653eff83d9ae72180fabd3d9cf616f14dd1871739963cd73L44

We ended up changing our implementation on the ruby side, which ended up setting data: null. This stops Apollo client from erroring because of type mismatch. We didn’t want to manually introduce a type override for each subscription we add. This approach allows us to support initial subscription result if we ever wanted to.

And we went from this in our cable stream

To this

And there were no more errors and all subscriptions kept on working as expected.

If you’re running into this error, it may help to consider adjusting the server, rather than waiting for Apollo client to ever change to support this. The issue is really with what restrictions ActionCable places on graphql-ruby for delivering subscriptions. By default, graphql-ruby is conffigured to NOT send a payload for initial subscription, but when it comes to ActionCable channels, it appears unavoidable that something will be sent and in this case it ends up being formatted incorrectly.

cc @rmosolgo

Thanks for sharing @hshoja, this fixed the issue for me when testing with React Testing Library and <MockedProvider />

fixed the error by adding fetchPolicy: "no-cache" in useSubscription

"@apollo/client": "3.7.16",
"@rails/actioncable": "7.0.6",
 "graphql-ruby-client": "1.11.8",

I am running into this issue because i have to use an await within “updateQuery”. As soon as i set “updateQuery” async the issue pop`s up. I could not find any guidance on that. Cant i use async at all in this context?

I get this error when I manually update cache via writeQuery.

To clarify the use case for maintainers, I have two types:

type Project {
    id: Int!
    name: String!
}

type App {
    id: Int!
    project: Project!
}

First I fetch projects with all fields:

query projects {
    projects {
        id
        name
    }
}

Then I manually update cache via writeQuery for the following query:

query apps {
    apps {
        id
        project {
            id
        }
    }
}

I’ll get Missing field 'name' while writing result error because the nested Project doesn’t contain name field. This in turn prevents my cache updates which causes all kinds of new issues.

I hoped I could fix it via typePolicies’s merge but the error happens before merge even called. So for now I have to fetch nested types with all fields for my cache writes.

I kiiiinda understand why this is the error (to be explicit about data updates/merge) and not a warning but I would really like to have a global option to make it a warning (or just ignore it completely), so my cache writes would go through and I would still be able to define the behaviour (e.g. use existing value if incoming is missing) in typePolicies’s merge.

I have had this issue for a while now and it’s still there in 3.7.0

This error is super misleading. In our case we had defined schema incorrectly. This error occurred when the actual field we were querying for during runtime didnt match up with the schema. Specifically it had to with returning a string when the type in the graph schema was Url. Changing to String in schema resolved the issue.

Hey guys, the way that I was able to solve this problem was by first checking if the data was there that I was writing. For me, this happened when I was doing cache.writeQuery, and the way I was able to solve it was just by checking if the data existed with an if statement. Hopefully, that helps 😃