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

In 3.1.0, resolve_type method on Interfaces and Unions no longer supports returning the GraphQL Type as a string #1555

Open
perlow opened this issue Jun 21, 2024 · 1 comment
Labels

Comments

@perlow
Copy link

perlow commented Jun 21, 2024

  • What is the current behavior?
    As of 3.1.0, the resolve_type method on Interfaces and Unions no longer supports returning the GraphQL Type as a string as opposed to the actual Graphene Type. I think this might be an unintended regression from Make Graphene compatible with GraphQL-Core 3.2 #1421.

  • What is the expected behavior?
    Our project heavily depends on resolve_type returning a string for the GraphQL Type as opposed to the Graphene Type that implements it.

  • What is the motivation / use case for changing the behavior?
    While it's possible to refactor most of our code to return the Graphene Type, there are some cases where it's very difficult to break circular imports. The reason for that is that some of our implementations of the resolve_type method delegates to returning a property of an Enum and the Enum definition can't reference the Graphene Type because the Graphene Type references the enum.

  • Please tell us about your environment:

    • Version: Trying to upgrade to 3.1.0.
    • Platform: Python 3.12.2 on Linux
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow)
    I created Allow resolve_type to return a string perlow/graphene#1 in a fork. I don't have write permission the repo to request a merge. If this looks reasonable, I can add a unit test for the behavior.

@erikwrede
Copy link
Member

Hey, thanks for the report. Can you share a little more about your use case, maybe with a code example to understand your situation better? 😊

For public repositories you can always open a PR from your fork by clicking new PR on the main Repo and selecting your fork branch: https://github.com/graphql-python/graphene/compare

Or simply via github cli, running gh pr create.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants