Using [IsProjected(true)] on SubSet which also contains at least one [IsProjected(true)] should not fail

[SonicYeager]

Is there an existing issue for this?

• [X] I have searched the existing issues

Product

Hot Chocolate

Describe the bug

When using IsProjected(true) on a SubType at a Type and querying for it (but not querying for the fields which has IsProjected(true)) results in: "A composite type always needs to specify a selection set.". More Details below.

Background:

At my company we struggle with projections and automapper as it seems not to work correctly. It always fetches everything or nothing. At a github-issue i found a workaround (see: https://github.com/ChilliCream/graphql-platform/issues/4114#issuecomment-1518695940). This fixes the problem for projections using automapper. Now we do have fields that relay on others and we therefore utilize "[IsProjected(true)]". Now, the Frontend not always queries for those fields. In those moments we have the above mentioned error. This seems to apply solemly on SubSets (see example below). Primitive fields (scalars of any kind) are not affected. This also is true when using Projections without automapper! I understand that an empty subset selection doesnt make sense, yet when using IsProjected so there is at least a single selection within the subset it should work!

Details as Simplified Example:

Book Type

public class Book : IType
{
    [IsProjected(true)]
    public int Id { get; set; } // Unique Identifier for the book
    public string Title { get; set; } // Title of the book
    [IsProjected(true)]
    public User Author { get; set; } // Author of the book
    public DateTime PublicationDate { get; set; } // Date when the book was published
    public string ISBN { get; set; } // International Standard Book Number
    public string Genre { get; set; } // Genre of the book
    public int PageCount { get; set; } // Number of pages in the book
    public string Language { get; set; } // Language in which the book is written
}

User Type

public class User
{
    [IsProjected(true)]
    public int Id { get; set; }
    public string Name { get; set; }
    public string SurName { get; set; }
}

Resolver

  [UsePaging]
    [UseProjection]
    [UseFiltering]
    [UseSorting]
    public IQueryable<Book> BooksFix([Service] CheckerDbContext checkerDbContext, IResolverContext resolverContext)
    {
        return checkerDbContext.Set<BookEntity>().ProjectToFix<BookEntity, Book>(resolverContext);
    }

Query selecting "[IsProjected(true)]" SubSet (works as expected)

query I {
  books {
    edges {
      node {
        id
        author {
          id
        }
      }
    }
  }
}

Query not selecting [IsProjected(true)] annotated SubSets (results in error)

query II {
  books {
    edges {
      node {
        id
      }
    }
  }
}

Steps to reproduce

Edit: Minimal reproduction at https://github.com/edvinnn/hc-isprojected-demo.

1. Using this Repository: https://github.com/SonicYeager/hotchocolate-checker
2. docker compose service:

mariadb:
    container_name: local_db
    image: mariadb:latest
    environment:
      - MARIADB_ROOT_PASSWORD=my-secret
    ports:
      - "3306:3306"
    restart: always

3. run migrations via: dotnet ef database update
4. run the project and use above queries to confirm findings

Relevant log output

No response

Additional Context?

No response

Version

13.3.1

[albernhagen]

I'm also encountering this issue. Is there any suggested workaround or are there plans to resolve it? I'm wondering if I should plan to live with this, wait for a good solution, or find some other implementation within our team.

[glen-84]

@SonicYeager

I'm not able to reproduce the error using your repository, I'm able to execute both queries successfully. Is this still an issue for you?

[SonicYeager]

@glen-84 Yes i can. Somhow i removed or forgot to add the [IsProjected(true)] annotation to public User Author { get; set; } at the Book Type. See above in the bug description. The Book Type implementation should match the one in the code. I pushed the correct one.

The "books" query runs, but ignores all [IsProjected(true)] annotations at the "user (Author)" subset. The other queries return the mentioned issue above.

I apologize for the inconvenience.

[glen-84]

Hmm. I'm still not able to reproduce the error. .NET SDK 8.0.101, WSL: Debian.

If you still get the error after clearing bin/ and obj/, maybe you could commit a package lock file to ensure that the same dependency versions are being resolved?

[SonicYeager]

Did you use those

query III {
  booksFix {
    edges {
      node {
        id
      }
    }
  }
}

query IV {
  booksSelection {
    edges {
      node {
        id
      }
    }
  }
}

as well?

I tried your suggestion and also tested it with the latest version (13.8.1) i can still reproduce the error there.

As said, this one seems to be fixed:

query II {
  books {
    edges {
      node {
        id
      }
    }
  }
}

[glen-84]

Did you use those

No, these queries were not in your initial comment.

I'm closing this issue now, as the initially-reported problem has been resolved, and the other problems relate to custom workarounds for other issues.

[edvinnn]

https://github.com/edvinnn/hc-isprojected-demo/tree/master

Here is a smal and concise demo project that is easy to run and illustrates the problem. There is a step by step guide to reproduce the problem in the readme of the repository. Would it be possible to re-open this issue?

[phebing]

Also experiencing this Issue (or a very close related one). As far as I understand the error on the query in the original question

query II {
  books {
    edges {
      node {
        id
      }
    }
  }
}

is thrown because the query only asks for the Id of books, but the book author's Id uses IsProjected and is kind of included. But there is no SelectionSet for the Author Property and that seems to be the Issue. https://github.com/ChilliCream/graphql-platform/blob/main/src/HotChocolate/Core/src/Execution/Processing/OperationCompiler.cs#L353

The other query

query I {
  books {
    edges {
      node {
        id
        author {
          id
        }
      }
    }
  }
}

creates a selectionSet on author and therefore works.

My use-case would look something like this: Books has a property AuthorSurname which is Resolved by Parent.Author.SurName. (So a resolver + IsProjected is used to map a related non key property to the top level object)

For now I have not found a good solution. Either accept that I have to go myBook.Author.Surname, or disable projections for the query.