Support a sub-selection on IAsyncEnumerable and ValueTask list fields - #555

Follow-up to #554. Same family of bug, two shapes that never got there because they fail earlier.

What is broken

An async service field returning IAsyncEnumerable<T> or ValueTask<TCollection> cannot have a sub-selection at all:

{ people { tags { name } } }

Field 'people' - No generic method 'SelectWithNullCheck' on type
'EntityGraphQL.Extensions.EnumerableExtensions' is compatible with the supplied
type arguments and arguments.

MakeSelectWithDynamicType resolves that overload by the exact type of the expression it projects, and only IEnumerable<T> and Task<IEnumerable<T>> had one. SetUpField already normalizes Task<TCollection> → Task<IEnumerable<T>> for exactly this reason; neither of these shapes was covered.

This is why #554 deferred the IAsyncEnumerable<T> branch of GetResolvedFieldType - the shape could not reach it. It is also why that PR's ValueTask<T> guard had nothing to guard yet: a ValueTask list with a sub-selection never compiled.

Fix

• IAsyncEnumerable<T> gets a SelectWithNullCheck overload of its own that projects lazily ([EnumeratorCancellation] async iterator). The field stays an IAsyncEnumerable through the whole pipeline, so the engine still buffers it - with the request's CancellationToken - instead of it being enumerated during compilation. Nothing about ConcurrencyLimitFieldExtension's deliberate IAsyncEnumerable exclusion changes.
• ValueTask<T> is handed on as the Task<T> the rest of the pipeline already handles, next to the existing Task<TCollection> normalization.

The bug underneath

Making these shapes compile made #554's bug reachable one layer down:

Object of type 'Dynamic_Dynamic_tags_…' cannot be converted to type 'Dynamic_tags_…'

BufferAsyncEnumerable created a List<T> from the declared element type up front and added each resolved item to it - but resolving an item rebuilds it when its projection holds an async member, so it no longer fits. The IEnumerable path already had this right: resolve first, then choose the list type from what you actually have (CanMaterializeTypedCollection). The async path now does the same, and both go through one shared MaterializeResolvedItems.

GetResolvedFieldType's IAsyncEnumerable<T> branch takes the same guard #554 added to Task<T>/ValueTask<T>, now that it can be reached.

Tests

Four new tests, each failing on main with the errors above:

• AsyncStreamShapeTests.AsyncEnumerableWithSubSelection
• AsyncStreamShapeTests.AsyncEnumerableWithAsyncFieldOnTheItem — the deferred shape
• ValueTaskShapeTests.ValueTaskOfListWithSubSelection
• ValueTaskShapeTests.ValueTaskOfListWithAnAsyncFieldOnTheItem — Keep a rebuilt async list's own type when the item type changed #554's bug through ValueTask

Release build green on net8.0/9.0/10.0: 1206 passed / 1 skipped, plus 47 EF and 92 AspNet on each.

No version bump - 6.2.4 is unreleased, so these two entries join it in the CHANGELOG.

Not included

One more shape turned up in the sweep and is left alone as unrelated: an async mutation returning a type that is not part of the context graph (Task<Tag> / Task<List<Tag>> where Tag came from AddType) fails with Cannot implicitly convert type 'void' to 'object'. The sync equivalent works, and so does Task<List<Person>>. Separate issue.

🤖 Generated with Claude Code