Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mutationType not working on type policies declaration #7443

Closed
zaguiini opened this issue Dec 10, 2020 · 4 comments
Closed

mutationType not working on type policies declaration #7443

zaguiini opened this issue Dec 10, 2020 · 4 comments
Assignees

Comments

@zaguiini
Copy link

Intended outcome:
To use a different mutation root type than Mutation.

Actual outcome:
Setting mutationType to true on the custom mutation type does not make any difference and Apollo attempts to write cache to Mutation instead of the desired one.

How to reproduce the issue:
It's proprietary code. I'll try my best to describe.
Root mutation is called TalentMutation. I've set:

{
  TalentMutation: {
    mutationType: true,
    fields: {
      talentPortalSetting: { merge: false }
    }
  }
}

Throws the following warning:

To address this problem (which is not a bug in Apollo Client), either ensure all objects of type TalentPortalSettingOps have an ID or a custom merge function, or define a custom merge function for the Mutation.talentPortalSetting field, so InMemoryCache can safely merge these objects.

Versions

  System:
    OS: macOS 10.15.7
  Binaries:
    Node: 14.8.0 - ~/.nvm/versions/node/v14.8.0/bin/node
    Yarn: 1.22.5 - ~/.nvm/versions/node/v14.8.0/bin/yarn
    npm: 5.1.0 - ~/Development/toptal/talent-portal-frontend/node_modules/.bin/npm
  Browsers:
    Chrome: 87.0.4280.88
    Edge: 87.0.664.57
    Firefox: 83.0
    Safari: 14.0
  npmPackages:
    @apollo/client: ^3.3.4 => 3.3.4
    apollo-upload-client: ^14.1.3 => 14.1.3

Additional information

It's properly working on 3.2.9. Not sure what's changed. I haven't seen anything relevant on the CHANGELOG, so it must be something changed by accident.

@benjamn
Copy link
Member

benjamn commented Dec 10, 2020

@zaguiini If you have a chance to try a manual binary-ish search, it would be useful to know which beta version of v3.3 introduced the regression. We had 18 betas (@apollo/client@3.3.0-beta.0 through -beta.17) and 6 RCs (-rc.0 through -rc.5). I don't know if there's a good way to use git bisect for this, but once you have a quick way to detect the problem, you can try a few of those versions and hopefully narrow things down from there. Let me know if you encounter anything weird/surprising along the way!

@benjamn benjamn self-assigned this Dec 10, 2020
@zaguiini
Copy link
Author

zaguiini commented Dec 11, 2020

Hey @benjamn, it was 3.3.0-beta.3 which introduced the regression. I'll try and find what went wrong.

EDIT: This is the commit which includes changes from beta 2 to beta 3. I think the problem lies on policies.ts changes, but I haven't got the time to investigate it further.

@benjamn
Copy link
Member

benjamn commented Dec 11, 2020

@zaguiini Thanks! That's a very useful clue for my investigation. 🙏

benjamn added a commit that referenced this issue Dec 11, 2020
Thanks to @zaguiini for tracking this regression (#7443) back to my
type/field policy inheritance PR (#7065).
benjamn added a commit that referenced this issue Dec 11, 2020
@benjamn
Copy link
Member

benjamn commented Dec 12, 2020

This should be fixed in @apollo/client@3.3.6 (just published). Please feel free to reopen if you're still having issues. Thanks!

@benjamn benjamn closed this as completed Dec 12, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants