Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Make `TryInferSchemaType` on `IDescriptorContext` public for use in custom type discovery handlers

Open Beginner friendly
  • Is something wrong?
#10,569 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, graphql
Domain
backend-api-design

Research direction

Read src/HotChocolate/Core/src/Types/Configuration/TypeDiscoveryDescriptorContextExtensions.cs and inspect how IDescriptorContext exposes type-discovery APIs. Make TryInferSchemaType and TryInferSchemaTypeKind publicly available with an appropriate namespace, then verify the change against the existing type-discovery tests and public API checks; done means custom handlers can call the methods without duplicating handler dispatch and the existing inference behavior remains unchanged.

Written by the indexing model from the issue text.

Description

🌶️ hot chocolate
Product

Hot Chocolate

Is your feature request related to a problem?

A custom TypeDiscoveryHandler sometimes needs to know what schema type another runtime type would be inferred as, in order to decide on its own result.

Our case: we have a generic scalar WildcardOrType<TInner, TInnerScalar> for a WildcardOr<T> runtime type, which wraps whatever scalar T maps to (WildcardOr<FlagField<SomePrivilege>> → WildcardOrType<FlagField<SomePrivilege>, FlagFieldType<SomePrivilege>>, WildcardOr<string> → WildcardOrType<string, StringType>, etc.). To pick TInnerScalar, the handler for WildcardOr<T> needs to ask "what would T be inferred as?" — and the answer may come from any handler, custom (another of ours, e.g. the one for FlagField<T>) or built-in (ScalarTypeDiscoveryHandler).

TypeDiscoveryDescriptorContextExtensions.TryInferSchemaType does exactly this, but it's internal:
https://github.com/ChilliCream/graphql-platform/blob/16.6.8/src/HotChocolate/Core/src/Types/Configuration/TypeDiscoveryDescriptorContextExtensions.cs

So we've had to replicate it on top of the (public) IDescriptorContext.GetTypeDiscoveryHandlers():

var typeRef = context.TypeInspector.GetTypeRef(runtimeType, typeContext);
var typeInfo = new TypeDiscoveryInfo(typeRef);

foreach (var handler in context.GetTypeDiscoveryHandlers())
{
    if (handler.TryInferType(typeRef, typeInfo, out var schemaTypeRefs))
        return schemaTypeRefs;
}

return null;

It's short, but it duplicates framework logic and would silently diverge if the way handlers are consulted ever changes.

The solution you'd like

Make TryInferSchemaType (and, for symmetry, TryInferSchemaTypeKind) on IDescriptorContext public — e.g. by moving TypeDiscoveryDescriptorContextExtensions out of internal, possibly into the HotChocolate.Internal namespace alongside TypeDiscoveryHandler and TypeDiscoveryInfo, if it shouldn't be considered fully public API.

This would let type discovery handlers that are generic over another type compose with all other handlers instead of re-implementing the dispatch.

Dominant language
C#
Stars
5.8k
Forks
810
Avg merge
14h 55m
Merged PRs (30d)
208

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ChilliCream/graphql-platform

All issues in ChilliCream/graphql-platform

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.