I've run a very simplistic benchmark, just returning a long list of single-field objects. It seems graphql-core-next is 2.5x slower than graphql-core: https://gist.github.com/ktosiek/849e8c7de8852c2df1df5af8ac193287

Looking at flamegraphs, I see isawaitable is used a lot, and it's a pretty slow function. Would it be possible to pass raw results around more? It seems resolve_field_value_or_error and complete_value_catching_error are the main offenders here.

Is it possible to serialize an instance of GraphQLSchema?

We would like to dump and load an instance of GraphQLSchema to/from a file for performance reasons.

It does not appear to be serializable using pickle by default.

>       res = pickle.dumps(schema)
E       AttributeError: Can't pickle local object 'extend_schema_impl.<locals>.build_object_type.<locals>.<lambda>'

Thanks in advance.

I have a use case where part of the schema is specified using the SDL, and part of the schema is generated in code. In particular, interfaces are in SDL, while the concrete types are in code. To correctly modify the GraphQLSchema object that is generated by parsing the initial schema, you need to:

• add the type concrete type to type_map
• add the type to _implementations_map appropriately
• reset _sub_type_map

Would you be open to adding an add_type method or similar that takes care of all of the above?

Usually I want to use the custom method binded to GraphQLObjectType, such as:

# use strawberry for example
import strawberry


@strawberry.type
class User:
    name: str
    age: int


@strawberry.type
class Query:
    @strawberry.field
    def user(self, info) -> User:
        return self.get_user()

    def get_user(self):
        return User(name="Patrick", age=100)


schema = strawberry.Schema(query=Query)

Unfortunately, the self would always be None cause the root_value in ExecutionContext.execute_operation would be setted to None if it is the root node Query. I think modifying it as below is fine:

def execute_operation(
        self, operation: OperationDefinitionNode, root_value: Any
    ) -> Optional[AwaitableOrValue[Any]]:
        """Execute an operation.

        Implements the "Evaluating operations" section of the spec.
        """
        type_ = get_operation_root_type(self.schema, operation)
        if not roo_value:
            root_value = type_

Then we can use the custom method of GraphQLObjectType. And it not leads any problem I think.

Today I've noticed apollo-client displaying warnings in console about queried fields missing from server's response:

At first I've thought that there's something wrong with Apollo client mistaking between fragments, but I've investigated server's response for query and GraphQL Playground, and realized that randomly, my query reuses result of one fragment where other fragment is expected:

This result occurs at random. Sometimes I always get valid query result. Sometimes I keep running into invalid query result.

Here's recording of this happening on Vimeo:

https://vimeo.com/418611363

I'm suspecting race condition within the Query executor, as it seems that moving category fields to bottom of thread seems to solve the issue, perhaps giving few more laps in the event loop for past subset to clean and new subset to be used?

I haven't seen this error occur for first fragment used within query, only for the latter one.

Follow up from https://github.com/graphql-python/graphql-core/pull/113

@Cito would love your thoughts on the best approach. I chose to convert FrozenList to effectively just be an alias for Tuple.

1. The FrozenList overrides hash (it also looks to be unsafe, in that the hash code would change if you reassigned an element, which is possible)
2. This allowed the existing isinstance(FrozenList) checks to still exist, while actually making the type immutable.
3. Having theses objects be truly immutable seems like a good idea, rather than simply expressing it in the type system.

I considered using https://github.com/tobgu/pyrsistent but was hesitant to include another third party library.

Add standard dunder attributes to (almost) all instances of __slots__

Using the test suite as a benchmark, this change produced no noticeable slow down.

Closes #81

This allows the type checks with mypy to pass in strict mode.

The reason for this is that we run type checks with mypy using the --strict mode which includes no_implicit_optional. This means that calls like e.g.

async def some_wrapper() -> ExecutionResult:
    schema: GraphQLSchema = ...
    query: str = ...
    variables: Optional[Dict[str, Any]] = ...
    return await graphql(schema, query, variable_values=variables)

fill fail the check with an error

src/mod.py:XXX: error: Argument "variable_values" to "graphql" has incompatible type "Optional[Dict[str, Any]]"; expected "Dict[str, Any]"

A possible workaround would be maintaining a private set of type stubs for the graphql package with optional types wrapped into Optional.

If you find the suggestion useful, I can extend this to the whole codebase. Of course, I understand that e.g.

def execute(
    schema: GraphQLSchema,
    document: DocumentNode,
    root_value: Any = None,
    context_value: Any = None,
    variable_values: Optional[Dict[str, Any]] = None,
    operation_name: Optional[str] = None,
    field_resolver: Optional[GraphQLFieldResolver] = None,
    type_resolver: Optional[GraphQLTypeResolver] = None,
    middleware: Optional[Middleware] = None,
    execution_context_class: Optional[Type["ExecutionContext"]] = None,
) -> AwaitableOrValue[ExecutionResult]:

starts to loose readability, but maybe it's time to introduce type aliases for common args; I find the current API great and already useable to be declared stable.

GraphQL spec section 7.1 describes a 3rd response field called extensions that is intended to be used for custom data in addition to payload data and error responses. This is often used for metadata related to the query response such as performance tracing. Apollo GraphQL implements this on their server via an extensions middleware. We should probably follow a similar pattern here but we will need to support passing the extensions data to the client in the core in order to support middleware like that.

https://graphql.github.io/graphql-spec/June2018/#sec-Response-Format

The response map may also contain an entry with key extensions. This entry, if set, must have a map as its value. This entry is reserved for implementors to extend the protocol however they see fit, and hence there are no additional restrictions on its contents.

Hi When you post an query with syntax errors graphql/graphene makes suggestions to you. By example, sending "i", it suggest "ID".

query{
  users{
        i
  }
}

{
  "errors": [
    {
      "message": "Cannot query field \"i\" on type \"User\". Did you mean \"id\"?",
      "locations": [
        {
          "line": 5,
          "column": 9
        }
      ]
    }
  ]
}

Can suggestions be disabled?

More info: Syntax analysis who add suggestions is executed before the middlewares. Apparently suggestions are made by ScalarLeafsRule class.

When parsing a query, the parser adheres to the original order, even in places where order shouldn't matter (arguments). This causes the two below queries to be marked as inequal by the comparator. Recommendation would be to sort any nodes for places where order doesn't matter, as part of optional_many.

We previously got around this issue by sorting the AST ourselves, but with the introduction of FrozenList, this now results in errors.

E       AssertionError: queryA =
E       {
E         vehicle(id: 3, otherId: 2) {
E           version
E           cancel
E           appointment {
E             when
E             afterDate
E           }
E           trigger {
E             how
E             Phase
E             PhaseOption
E             PhaseDelaySecs
E           }
E         }
E       }
E       
E        queryB =
E       {
E         vehicle(otherId: 2, id: 3) {
E           version
E           cancel
E           appointment {
E             when
E             afterDate
E           }
E           trigger {
E             how
E             Phase
E             PhaseOption
E             PhaseDelaySecs
E           }
E         }
E       }

I'm trying to figure out a way to return None for non-nullable fields if the requesting user doesn't have permission to view them.

I was trying to pass Undefined from graphql.pyutils.undefined, but it doesn't work. It looks like the second check in this line

# If result value is null or undefined then return null.
if result is None or result is Undefined:
    return None

can never run because Undefined is actually a descendant of ValueError and therefore triggers this check.

if isinstance(result, Exception):
    raise result

I don't know if this was meant as an escape hatch for returning null values if you really wanted to (which is what I really need right now), but the code itself seems wrong either way.

Bumps certifi from 2022.9.24 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hello, thanks for graphql-core. I use it often in my projects with GraphQL.

I created my project for pydantic model generation from some graphql schema. And for graphql queries generation from python classes. This project based on graphql-core. The project URL is https://github.com/denisart/graphql2python

I was motivated by a famous project https://the-guild.dev/graphql/codegen/docs/getting-started. But my project so far has few settings. This will be fixed in future releases. Now you can to generate a file with pydantic classes from some GraphQL schema. You can see examples in https://denisart.github.io/graphql2python/query.html https://denisart.github.io/graphql2python/model.html

I hope that the developments in this project can be useful for the community.

TLDR: I would like graph-core to tell me what "leaf" nodes from my query need returned. Allow me to fetch the data through whatever method I deem efficient. Then I would like graph-core to take care of returning the data. The current asyncio implementation, seems to fundamentally not work for this.

I've been digging in deep on a graphql-core build recently and have stumbled across this interesting problem. If I've missed a key feature of the library here, than please point it out.

To me, the ideal way to use the core library is to:

1. Use graph-core to decide what data to retrieve.
2. Use a separate data loading engine to read the data.
3. Use graph-core to return the data.

Its interesting to see where this problem fits in as either a graphe-core-3 issue, needing a feature, or a graphql issue. The essential catch is this, it's very hard to determine when the graph-core resolution has finished deciding what leaves from the graph need fetched. Here's an example to illustrate the point.

##########################################################
## TEST GRAPHE SCHEMA BASED ON ASYNCIO ######################
##########################################################
from graphql import (
    GraphQLBoolean, graphql, GraphQLSchema, GraphQLObjectType, GraphQLField, GraphQLString)
import logging
import asyncio

_logger = logging.getLogger('GrapheneDeferralTest')
_logger.setLevel('DEBUG')

query = """
{
    ioHMIControls {
        EStopHMI,
        JogHMI,
    }
}
"""

async def resolve_EStopHMI(parent, info):
    _id = '_EStopHMI_id'
    info.context['node_ids'][_id] = None
    await info.context['awaitable']
    return info.context['node_ids'][_id]
EStopHMI = GraphQLField(
    GraphQLBoolean,
    resolve=resolve_EStopHMI
)

async def resolve_JogHMI(parent, info):
    _id = '_JogHMI_id'
    info.context['node_ids'][_id] = None
    await info.context['awaitable']
    return info.context['node_ids'][_id]
JogHMI = GraphQLField(
    GraphQLBoolean,
    resolve=resolve_EStopHMI
)


def resolve_ioHMIControls(parent, info):
    return ioHMIControls
ioHMIControls = GraphQLObjectType(
    name='ioHMIControls',
    fields={
        'EStopHMI': EStopHMI,
        'JogHMI':JogHMI,
    }
)

def resolve_GlobalVars(parent, info):
    return GlobalVars
GlobalVars = GraphQLObjectType(
    name='GlobalVars',
    fields={
        'ioHMIControls': GraphQLField(ioHMIControls, resolve=resolve_ioHMIControls)
    }
)

async def simulate_fetch_data(_ids):
    print(_ids)
    await asyncio.sleep(1)
    return {k:True for k in _ids.keys()}
    
async def main():
    # Objective:
    #     1. Have graph determine what data I need by partially resolving
    #     2. Pause graph resolution.
    #     3. Collect data into a `data_loader` object.
    #     4. Retrieve data via `data_loader` object.
    #     5. Resume graph resolution with loaded data.

    # 3. collect ids of data fields into a dict
    _ids = {}

    #2. pause graph resolution by awaitn a future
    future = asyncio.Future()
    context = {
        'node_ids': _ids,
        'awaitable': future,
    }
    schema = GraphQLSchema(query=GlobalVars)

    # 1. Determine WHAT data to return
    resove_graph_task = asyncio.create_task(graphql(schema, query, context_value=context))

    # ?
    # There is no way to detect that resolve_graph_task
    # has finished fillin _ids dict with id values.

    # 4. Fetch the data
    fetch_data_task = asyncio.create_task(simulate_fetch_data(_ids))

    # ? 
    # This await doesn't work in this order or any order
    # becaus of the interdependancy of both tasks, coupled with 
    # the mechanics of asyncio.
    await fetch_data_task

    # 5. Resume graph resolution with retrieved data.
    future.set_result(0)

    # ? 
    # return the data from the graph, as a graph result. 
    # problem, is that the data is not there due to 
    # interdependancy between await tasks. 
    result = await resove_graph_task
    print(result)

if __name__ == '__main__':
    asyncio.run(main())

Results

{}
ExecutionResult(data={'ioHMIControls': {'EStopHMI': None, 'JogHMI': None}}, errors=None)

The example is a little long, but I wanted it to be sufficiently complex. The gist is that there is no way in the current asyncio implementation to determine that: all resolvers have been reached.

Looking at the implementations we could use some advanced event systems to manage this, but it would be a bit of work. Another possible solution could be to allow resolvers to return coroutines and put off type checking till those coroutines are themselves resolved. I think, this may be the most elegant method.

Thoughts?

PR - https://github.com/graphql-python/graphql-core/pull/168

I use graphene and graphene-pydantic libraries. Code example. You can run this for testing. https://gist.github.com/dima-dmytruk23/aaeba0fbc7a539c1f8bf3d0914fce580

The client does not pass the name field, but it is still present in the mutation as None. Input query turns into a UserUpdateInput, which is when the default values are filled in to the dictionary. So then when code passes the dictionary in to build the UserUpdate, it sets all the fields -- so exclude_unset doesn't exclude anything, since all the fields were in fact set.

I am fairly sure it's not in graphene-pydantic, though, since that is only responsible for converting to the GrapheneInputObjectType.

I propose to resolve this issue by adding the exclude_unset flag to the GraphQLSchema class and use it in the coerce_input_value function.

Original discussion: https://github.com/graphql-python/graphene-pydantic/pull/75

I use graphene and graphene-pydantic libraries. Code example: https://gist.github.com/dima-dmytruk23/aaeba0fbc7a539c1f8bf3d0914fce580

The client does not pass the name field, but it is still present in the mutation as None. Input query turns into a UserUpdateInput, which is when the default values are filled in to the dictionary. So then when your code passes the dictionary in to build the UserUpdate, it sets all the fields -- so exclude_unset doesn't exclude anything, since all the fields were in fact set.

I am fairly sure it's not in graphene-pydantic, though, since that is only responsible for converting to the GrapheneInputObjectType.

I propose to resolve this issue by adding the exclude unset flag to the GraphQLSchema class and use it in the coerce_input_value function.