Apollo-client: Getting Store Errors after upgrading to v1.0.0

[Siyfion]

Since upgrading from a previous release candidate (rc6), I am now getting errors when running _ALL_ of my create/delete mutations, regardless of what data they mutate I always get the same error:

Allergen.jsx:38 Error: Error: Store error: the application attempted to write an object with no provided id but the store already contains an id of Site:developer for this object.
    at writeFieldToStore (http://localhost:3000/packages/modules.js?hash=c1dea742144f5f0b244684fb3a95fddf714f326e:49816:23)
    at http://localhost:3000/packages/modules.js?hash=c1dea742144f5f0b244684fb3a95fddf714f326e:49709:17
    at Array.forEach (native)
    at writeSelectionSetToStore (http://localhost:3000/packages/modules.js?hash=c1dea742144f5f0b244684fb3a95fddf714f326e:49703:29)
    at writeResultToStore (http://localhost:3000/packages/modules.js?hash=c1dea742144f5f0b244684fb3a95fddf714f326e:49688:12)
    at http://localhost:3000/packages/modules.js?hash=c1dea742144f5f0b244684fb3a95fddf714f326e:51277:20
    at http://localhost:3000/packages/modules.js?hash=c1dea742144f5f0b244684fb3a95fddf714f326e:50464:34
    at Array.forEach (native)
    at data (http://localhost:3000/packages/modules.js?hash=c1dea742144f5f0b244684fb3a95fddf714f326e:50463:43)
    at apolloReducer (http://localhost:3000/packages/modules.js?hash=c1dea742144f5f0b244684fb3a95fddf714f326e:50675:23)
(anonymous) @ Allergen.jsx:38
(anonymous) @ meteor.js?hash=27829e9…:1105

In this particular instance I was attempting to delete an Allergen.

For reference here is the relevant client-side code:

const Allergen = ({ ..., removeAllergen }) => {
  const onDelete = () => {
    bootbox.confirm(`Are you sure that you wish to delete allergen '${allergen.name}'?`,
      (result) => {
        if (!result) return;
        removeAllergen({ id: allergen._id }).catch((methodError) => {
          toastr.error('An error occurred when attempting to delete the allergen');
          console.error('Error:', methodError);
        });
      },
    );
  };

  ...
};

const removeAllergen = gql`
  mutation removeAllergen($id: String!) {
    removeAllergen(id: $id)
  }
`;

const AllergenContainer = compose(
  graphql(removeAllergen, {
    props({ mutate }) {
      return {
        removeAllergen({ id }) {
          return mutate({
            variables: { id },
          });
        },
      };
    },
  }),
)(Allergen);

export default AllergenContainer;

and the server-side mutation:

export const schema = [`
  type Allergen {
    _id: String!
    createdAt: Date
    updatedAt: Date
    site: Site!
    siteId: String!
    name: String!
  }
`];

export const mutations = `
  # Deletes the specified allergen
  removeAllergen(id: String!): String
`;

export const mutationResolvers = {
  removeAllergen(root, { id }, context) {
    if (!context.user) throw new Meteor.Error('allergens.removeAllergen.login', 'Must be logged in.');

    const allergen = Allergens.findOne({ _id: id });
    if (!allergen) throw new Meteor.Error('allergens.removeAllergen.notFound', 'The specified allergen does not exist');
    userIsOwner(allergen, context.user);

    // Remove the allergen from the database and return the id of the removed document
    const docsRemoved = Allergens.remove({ _id: id });
    return docsRemoved === 1 ? id : null;
  },
};

[Siyfion]

Rolling apollo-client back to v1.0.0-rc.6 makes it all work again... I'll continue testing the versions in between to try to narrow the issue down...

However I can confirm that v1.0.0-rc.7 breaks all my mutations. So the issue was likely introduced there.

[Siyfion]

I'm starting to think that it might be related to the reducer functions so for completeness I'll add them too:

import update from 'immutability-helper';

const dataQuery = gql`
  query getAllergenInfo {
    allergens {
      _id
      siteId
      name
    }
    site {
      _id
      siteSettings {
        allergenPrefix
      }
    }
  }
`;

const AllergensPageContainer = compose(
  graphql(dataQuery, {
    props: ({ data }) => {
      if (data.loading) return { loading: true };
      if (data.error) return { error: data.error };
      return {
        allergens: data.allergens,
        site: data.site,
      };
    },
    options() {
      return {
        reducer: (previousResult, action) => {
          if (action.type === 'APOLLO_MUTATION_RESULT' && action.operationName === 'insertAllergen') {
            const newAllergen = action.result.data.insertAllergen;
            return update(previousResult, {
              allergens: {
                $unshift: [newAllergen],
              },
            });
          } else if (action.type === 'APOLLO_MUTATION_RESULT' && action.operationName === 'removeAllergen') {
            const removedId = action.result.data.removeAllergen;
            if (!_.isString(removedId)) return previousResult;
            const index = _.findIndex(previousResult.allergens, { _id: removedId });
            if (index === -1) return previousResult;
            return update(previousResult, {
              allergens: {
                $splice: [[index, 1]],
              },
            });
          }
          return previousResult;
        },
      };
    },
  }),
)(AllergensPage);

[helfer]

@Siyfion could you provide a reproduction using react-apollo-error-template? That would help us find and fix the issue faster.

[rdickert]

I saw a similar issue upgrading a client app to 1.0.0. I don't have time to give a good repro, but I thought I'd mention our code uses reducer code very similar to @Siyfion 's, in case that helps. We were at rc6 when we found the issue and have set the upgrade aside for the time being.

[helfer]

@rdickert I'm assuming you're also using meteor-integration, right?

[xavxyz]

I've tried to help @Siyfion solving this issue, here are which assumptions have come out after our discussion (assumptions as in my knowledge of the internals of apollo-client is limited).

The error happens when updating the store after a mutation succeeded: part of the reducer output conflicts with what is already there in the store, resulting in the error Store error: ....

Looking at the code related to the error, we are in the case of a generated id is already in place for the new id we want to insert. The "funny thing" is that, in the case of the issue raised, the id causing trouble isn't the added/removed result, it's an id of another type already present :sweat_smile:.

The query asks for allergens & site, the mutation updates allergens, the error is on site (screenshot of a breakpoint just before the error):

• the escapedId, already present, is Site:developer (Site is the typename, developer is the id);
• the new storeValue is generated, it's $ROOT_QUERY.site.

Could the problem come from an inconsistency in the way of asking for data corresponding to site ?

The query asks for site on the root, but also on the allergen with siteId. siteId being resolved as:

export const resolvers = {
  Allergen: {
    site: ({ site }) => Sites.findOne({ _id: site }),
    siteId: _.property('site'),
  },
};

I don't see in the changelog what could have caused the version upgrade triggering that kind of behavior? About the meteor-integration, the only real thing it does is plugging a new value on the headers on every request send, so I don't exactly see how it could cause the issue.

Hope it helps!

[Siyfion]

Just to confirm that the issue still exists in v1.0.1 and that I believe @SachaG is also suffering from this issue?

[wmertens]

@xavcz so the error is that your mutation somehow also returns a site that "conflicts" with a site already in the cache?

[Siyfion]

@wmertens The mutation doesn't return anything at all to do with a Site, in fact I get an error when dealing with the removeAllergen mutation which only returns a simple String.

[SachaG]

I can confirm I've been running into pretty clear-cut issues with mutation updates. I'm not using meteor-integration btw.

[abhiaiyer91]

I hit this error so I did 2 things:

1. I added the addTypename attr to my ApolloClient constructor
2. I specified __typename in all my relevant queries that the mutation touched

The fact that I had to do those things seemed weird, but bigger fish to fry on my end.

[Danjavia]

Hi I have this error after mmigrate to v1.0.1

Network error: Store error: the application attempted to write an object with no provided id but the store already contains an id of UserNodeVXNlck5vZGU6MTUwNjA= for this object.

can someone help me?

Thank you!

[helfer]

Thanks all! A reproduction with react-apollo-error-template would really help here, but I'll see if I can figure out what's going on without it.

[SachaG]

I can confirm @abhiaiyer91's fix seems to work for me using 1.0.1.

[helfer]

Ok, after thinking for bit and looking at the code I'm fairly sure I know what's going on. The issue is that reducer takes its query from observableQuery.options.query, which does not yet have the addTypename transform applied.
The workaround is to add __typename to all selection sets in queries that have a reducer. I'm not sure if updateQueries has the same issue (it's not trivial to check), but update doesn't, because I recently fixed it (I think).

The quick solution would be to apply the addTypename transform every time the reducer runs (it's pretty cheap).
A slightly longer term solution might be to just apply addTypename as soon as the document enters ApolloClient through query or watchQuery, as we do for mutate.
In the long term, we'd like to apply the transform only where it's really necessary, and return only the selections that the user originally requested, not including __typename if it wasn't asked for.

PS: It's interesting that this only showed up after we created a default dataIdFromObject function. I would have assumed that such a problem would show up much sooner. It guess it shows that most people weren't using dataIdFromObject.

[abhiaiyer91]

@helfer This issue occurs in update and reducer surprisingly not in updateQueries for version 1.0.0 not sure if the fix you describe for update is in 1.0.1

[Siyfion]

@abhiaiyer91 The fix isn't in v1.0.1 @helfer is still working on it I believe.

[ViggoV]

I know this one is closed, but I am getting this error after updating from 0.10.1 to 1.3.0.. Are you sure that it is fixed? I am not using meteor..

EDIT: Never mind. It turned out that I had an EventList query which cached events by their id and an Event query that didn't include said id. Maybe this can help someone else :)