Issue with HotChocolate GraphQL

[Kasacka]

Hi everybody. I have a problem with HotChocolate Projection and hope somebody can help me with that.
In my query I added the following attributes (also the attribute UseProjection)

Additionally I have resolvers like this which works perfectly fine as long I mark the field DateOfBirth as IsProjected or ask for the field DateOfBirth in the query.

No to the problem. If I have a calculated field by a resolver which uses another table (foreign key navigation). Then the IsProjected does not work properly. When I don't ask for the navigated field PersonComments.

Does anybody know this problem.

[MelGrubb]

THIS!!!

This is absolutely killing me. I have a calculated field implemented as a custom field resolver. It depends on information from two navigation properties over. Those objects do not appear in the query itself, so those objects are never loaded. When the custom field resolver tries to run, they are null. Under v13 they were lazy-loading proxies and things just worked. It wasn't as efficient, but it worked. I am trapped on v13 until I can solve this.

After multiple efforts to solve this myself, I have unleashed a Claude Opus instance will full autonomy to try to solve this. It has run for hours every day off to the side, silently trying and failing to come up with a viable workaround. Every proposed solution fixes something at the expense of something else. My current idea is to just say "screw it" in the custom field resolver, grab the context and do it myself just so that we can update to v14/v15/v16 in the hope that somehow this will be possible in the future, but I can't make it past step 1. Just make my code WORK in v14. I WANT to update this code. I WANT to fix this problem in a more proper way. But I can't.

[MelGrubb]

If I can baby-step my way to 15, then this is exactly the sort of thing I'm looking for. How would that work with multiple steps? For instance, the Foo.Bar field resolver requires the field Bar.Baz.Qux.

[tobias-tengler]

You use GraphQL syntax to require fields: [Parent(requires: "bar { baz { qux } }")]. You can also select multiple fields per level by separating them with a space.

[MelGrubb]

That, I like. I may have to attempt to leapfrog v14 entirely. That's not going to be as easy, but I've burned too much time stuck on this issue.

[MelGrubb]

I have tried the Parent(requires: syntax, and while it works for same-entity properties, like saying that the FullName field requires the FirstName and LastName fields, I can't get it to work with properties of child objects. I gave it numerous tries by hand and got nowhere.

Finally, I gave Claude a full clone of the Chillicream repository for reference and turned it loose overnight to see what it could figure out. Claude bashed away at it, and gave up by the morning. I'm not yet in the "let AI solve everything" camp, but I have wasted so many hours trying to get this relatively simple thing to work that I just can't do it anymore. Short of hand-writing individual resolvers for every single query in existence, how is anyone using HC for serious work when it can't handle the simplest of navigation properties?

Here is what Claude reported, and I understand what it's saying.
tl;dr - You can't use the ParentRequires syntax in the only situation that you would want to.

Problem

  ParentRequires<T>() and [Parent(requires: "...")] do not work when used with [UseProjection] on EF Core queries.

  Root Cause

  HotChocolate has two separate projection systems that don't share field requirements:

  1. HotChocolate.Execution.Projections (SelectionExpressionBuilder)
    - Reads FieldRequirementsMetadata populated by RequirementsTypeInterceptor
    - Honors ParentRequires<T>() and [Parent(requires: "...")]
  2. HotChocolate.Data.Projections (QueryableProjectionVisitor)
    - Triggered by [UseProjection] attribute
    - Does NOT read FieldRequirementsMetadata
    - Only projects fields based on the GraphQL selection set

  Evidence

  When using:
  descriptor
      .Field("sessionReport")
      .ParentRequires<Session>("Staff Plan { Staff } AllActivities")
      .Resolve(ctx => FooReport.FromModel(ctx.Parent<Session>()));

  With a query method decorated with [UseProjection]:
  [UseProjection]
  public IQueryable<Session> GetSessionById(Guid id, ...)
      => dbContext.Sessions.Where(x => x.Id == id);

  The navigation properties (Staff, Plan.Staff, AllActivities) are not included in the EF projection. The resolver receives a Session with null navigation properties.

  Expected Behavior

  ParentRequires<T>() requirements should be injected into the QueryableProjectionVisitor's projection expression, causing EF Core to JOIN/Include the required navigation properties.

  Workaround

  Use defensive resolvers that query the database directly when navigation properties aren't loaded or avoid [UseProjection] for entities with resolvers that need navigation properties.

[MelGrubb]

The best "key insight" I've gotten from this interaction with Claude is that the ChilliCream project seems to have no examples or tests that combine the use of "UseProjection" and the requires mechanism. This suggests that
a) The two mechanisms were never designed to work together, and I'm simply doing it wrong, or
b) They were meant to work together but somehow don't, in which case it's a bug

My goal is simply to convince HC to write efficient SQL that doesn't lazy-load or over-fetch. Projections seem to be meant for exactly that, but can't handle navigation properties to objects that aren't explicitly mentioned in the original query. The "Parent Requires" mechanism is meant for specifying that such navigation properties are needed, but seems to fall apart if you try to use it and projections at the same time.