Info being Strawberry Info everywhere

[patrick91]

Make strawberry.Info the canonical and ergonomic Info type across Strawberry's user-facing resolution APIs before V1.

Scope

Internal graphql-core adapters necessarily receive GraphQLResolveInfo. The goal should be consistency for callbacks and hooks implemented by users, rather than mechanically replacing every internal use. Any user-facing callback that intentionally keeps GraphQLResolveInfo should be an explicit, documented V1 decision.

Current audit

Already using Strawberry Info

• Export Info as strawberry.Info
• Field, mutation, and subscription resolvers receive strawberry.Info (or the configured info_class)
• Permissions and field extensions receive Strawberry Info
• Exception handlers, Federation resolve_reference, and Strawberry Relay resolver hooks receive Strawberry Info
• Operation-directive resolvers receive Strawberry Info, including custom info_class subclasses

The raw GraphQLResolveInfo annotation in strawberry/extensions/directives.py is on the internal SchemaExtension middleware boundary. process_directive wraps it with schema.config.info_class before invoking the user-authored directive resolver, so directive resolvers themselves are not currently a gap.

User-facing APIs still receiving GraphQLResolveInfo

• SchemaExtension.resolve receives GraphQLResolveInfo; the custom-extensions guide also documents this raw type
• User-defined object is_type_of hooks receive GraphQLResolveInfo
• User-defined interface resolve_type hooks receive GraphQLResolveInfo
• OpenTelemetryExtension's public arg_filter callback receives GraphQLResolveInfo
• Audit other public callbacks exposed by schema/built-in extensions and either migrate them or document why they intentionally remain graphql-core APIs

Raw info used only inside the schema converter, union resolution, tracing implementations, selection conversion, and other graphql-core adapters should remain an implementation detail unless it is passed through a public callback.

Directive-specific gap

There are two distinct directive concerns:

• The info argument passed to an operation-directive resolver is already Strawberry Info.
• Directive arguments exposed through info.selected_fields[*].directives are converted by strawberry/types/nodes.py into plain Python values. Nested Strawberry input objects therefore remain dictionaries instead of their declared Strawberry input type. This is tracked by Conversion into strawberry type on directives in the info object #3155 and is still reproducible.

Remaining decisions and work

• Decide whether all user-authored resolution callbacks above should receive the configured info_class, including custom subclasses
• Define how SchemaExtension.resolve and its _next chain expose Strawberry Info while preserving the graphql-core middleware boundary
• Preserve access to the underlying object through Info._raw_info for users that need graphql-core details
• Add runtime tests for each migrated callback, including custom info_class coverage and sync/async paths where applicable
• Update the custom-extension and type-resolution documentation
• Add migration documentation/release notes for callbacks changing from GraphQLResolveInfo, since these are runtime breaking changes
• Resolve or explicitly scope the related Info | None annotation ergonomics in Support Union[strawberry.Info, None] annotation for Info. #4389

Related

• Strawberry V1 Milestone #4239
• Info type is annoying to access #2768
• Improve support for Info and similar when used with TYPE_CHECKING blocks #2889
• Conversion into strawberry type on directives in the info object #3155
• Support Union[strawberry.Info, None] annotation for Info. #4389