Variables set on mutate function override one set on useMutation hook

[0777101]

Intended outcome:

Variables passed to mutate function and variables set on useMutation merged together into one object

Actual outcome:

Variables passed to mutate function override what was set on useMutation

How to reproduce the issue:

const [updateThing] = useMutation(UPDATE_THIS_GQL, {
  variables: {
    id: thingId
  }
});

...

const result = await updateThing({
  variables: {
    ...otherValuesButId
  }
});

Versions

I believe that this was introduced by b273d03, specifically by removing this code:

const mutateVariables = Object.assign(
  {},
  variables,
  mutateOptions.variables
);

[yograf]

I'm trying to figure out if this is a bug or intended?
from the docs "Any options you provide to a mutate function override corresponding options you previously provided to useMutation"
??

[tyler-dot-earth]

I would also like to know if this is intended behavior; I have several mutations that rely on initially-set variables getting merged with the mutate function automatically. Gonna need to do some extra plumbing as part of the v3 migration if this change is intended behavior.

[ericArbour]

This gave me some issues when migrating to "@apollo/client": "^3.1.2". Interestingly, I verified that useLazyQuery still merges the callback and hook variables together.

[hwillson]

Is this issue still happening with >= @apollo/client@3.1.0? I'm surprised it wasn't fixed by #6715.

[ericArbour]

@hwillson I just tested with @apollo/client@3.1.3 and can confirm this behavior is still occurring. Thanks!

[0777101]

I'm surprised it wasn't fixed by #6715.

@hwillson
That is because compact utility function, used in #6715, doesn't have a recursion. It sets (override) result.variables to the value found in mutationFunctionOptions, but to fix the issue it should merge (combine) it with what was found in this.getOptions()

[hwillson]

Thanks @ericArbour @0777101 - I'll take a closer look.

[Nedomas]

Can confirm that this bug exists at least from >=3.0.0.

[amannn]

I also noticed this behaviour in @apollo/client@3.1.4

[amannn]

I've added a PR which should fix this 🙂

#6927

[Nedomas]

This is a blocking issue for us to migrate to v3 currently. Thanks @amannn! Looking forward for #6927 to be merged.

[ianks]

we're blocked by this as well. looks likes #6927 was merged. any chance this gets released in v3.2.1?

[Alttaf]

we are blocked by this at the moment too, we really want to move to v3

[hwillson]

Let us know if this is still a concern with @apollo/client@latest - thanks!