graphql-core coerce_string used instead of graphene.String

首先跟踪 graphene/types/schema.py 中对标量的处理，并将 graphene/types/scalars.py 与 graphql/type/scalars.py 进行比较。使用 graphene.test.Client.execute 重现 HttpUrl 情况，然后确定预期的修复是保留 graphene.String 的强制转换，还是使其与 graphql-core 保持一致。当行为和预期的强制转换都由回归测试覆盖时，即视为完成。

Note: for support questions, please use stackoverflow. This repository's issues are reserved for feature requests and bug reports.

• What is the current behavior?

Not 100% sure this is a bug, but it seems not quite right.

graphene.String has the following coerce_string method:
https://github.com/graphql-python/graphene/blob/master/graphene/types/scalars.py#L144

This should mean that any value that is resolved via a graphene.String field gets cast to str

In contrast, graphql-core has this coerce_string method:
https://github.com/graphql-python/graphql-core/blob/a2d52df815f81a62649ee637999fc241af1e67a3/src/graphql/type/scalars.py#L176

...note that in graphql-core any value which passes an isinstance(val, str) check will not get cast to str.

I noticed this because I am using pydantic HttpUrl type in my parent object, the value is an HttpUrl instance (which passes an isinstance(val, str) check).

I noticed in my test cases that the HttpUrl value passes untouched through the graphene.test.Client.execute flow.

Looking at the graphene src this was puzzling because it seemed like it should get cast down to a plain string.

Stepping through with ipdb, I could see in complete_value method:

ipdb> pp result
HttpUrl('https://example.com/test-url, scheme='https', host='example.com', tld='com', host_type='domain', path='test-url')
ipdb> return_type
<graphql.type.definition.GraphQLScalarType object at 0x1059876a0>
ipdb> import inspect
ipdb> inspect.getsource(return_type.serialize)
'def coerce_string(value):\n    # type: (Any) -> str\n    if isinstance(value, string_types):\n        return value\n\n    if isinstance(value, bool):\n        return u"true" if value else u"false"\n\n    return text_type(value)\n'
ipdb> inspect.getsourcefile(return_type.serialize)
'/lib/python3.8/site-packages/graphql/type/scalars.py'

...so we have a graphql-core field rather than a graphene one, which explains why the cast to str didn't happen.

I am guessing it may be due to this code:
https://github.com/graphql-python/graphene/blob/f039af2810806ab42521426777b3a0d061b02802/graphene/types/schema.py#L148

Which raises the question... are the methods on graphene.String and friends just dead code?

Or if they're still used in some other circumstance, should they maybe delegate to corresponding graphql-core methods for sake of consistency, rather than having their own subtly different implementation?

If I change my type def to:

import graphene

class HttpUrl(graphene.String):
    pass

class MyParent(graphene.ObjectType):
    some_url = HttpUrl(required=True)

...then I get the graphene casting behaviour, again I think because we fall thru this check https://github.com/graphql-python/graphene/blob/f039af2810806ab42521426777b3a0d061b02802/graphene/types/schema.py#L148 and don't substitute a graphql-core type.

In the end this behaviour didn't break anything for me, but it's probably possible to imagine a scenario where it would.